Skip to main content
The ServiceNow CMDB integration connects Draftt’s resource inventory to your Configuration Management Database. When your organization maintains authoritative ownership and service data in ServiceNow, Draftt reads that data as a high-confidence ownership signal, eliminating duplicate ownership maintenance and ensuring governance findings reach the right teams.

Why CMDB Matters for Ownership

Most cloud resource ownership signals (tags, CODEOWNERS files, IDP catalog) reflect what teams intend. CMDB reflects what your ITSM system has officially recorded, often the most authoritative source in large, regulated organizations. When CMDB data is connected:
  • Draftt resolves resource owners from CI (Configuration Item) records, not just cloud tags
  • Teams managing CIs in ServiceNow don’t need to re-declare ownership in Draftt
  • Governance findings are routed to the correct assignment group as defined in CMDB
  • Orphaned resource counts drop significantly because CMDB coverage typically exceeds tag coverage in mature environments

How the Integration Works

Draftt queries your ServiceNow CMDB to correlate CIs with resources in its inventory. The correlation uses:
  • Resource identifiers - Cloud resource IDs, ARNs, and instance names matched against CI attributes
  • IP addresses and hostnames - For infrastructure resources not identified by cloud-native IDs
  • Service mapping - If ServiceNow Service Mapping is configured, Draftt can resolve service-level ownership from application CIs
Once a correlation is established, the owning assignment group and responsible manager from the CI record become ownership signals in Draftt alongside cloud tags and IDP catalog data. The CMDB integration uses read-only access only. Draftt does not write to your CMDB.
CMDB ownership signals have the same priority as IDP catalog signals in Draftt’s ownership resolution. Cloud tags take precedence. See Resource Ownership for the full priority order.

Supported CI Classes

Draftt reads the following CI classes from ServiceNow CMDB:
CI ClassMaps To
cmdb_ci_vm_instanceCloud VMs (EC2, Azure VMs, GCP Compute)
cmdb_ci_cloud_databaseManaged databases (RDS, Azure SQL, Cloud SQL)
cmdb_ci_kubernetes_clusterKubernetes clusters
cmdb_ci_cloud_storage_bucketCloud storage (S3, Azure Blob, GCS)
cmdb_ci_cloud_functionServerless functions (Lambda, Azure Functions)
cmdb_ci_app_serverApplication servers and services
cmdb_ci_serviceBusiness services (for service-level ownership)
Additional CI classes can be added on request.

Setup

The CMDB integration uses the same ServiceNow connection as Draftt’s ticketing integration, if already configured. You can add CMDB access to an existing connection or create a dedicated one.

Step 1: Grant CMDB read roles

Your ServiceNow service account needs the following roles in addition to any already granted for ticketing:
  • cmdb_read: Read access to all CMDB tables
  • itil: Access to service and assignment group data
If you created a dedicated service account for Draftt during ticketing setup, add these roles to that account. In ServiceNow, navigate to User Administration > Users, open the Draftt service account, go to the Roles tab, and add cmdb_read and itil.

Step 2: Enable CMDB in Draftt

Go to Integrations > Platform > ServiceNow. If a ServiceNow connection already exists, click Configure > CMDB. If not, complete the ServiceNow ticketing setup first. Toggle CMDB Ownership Sync on. Draftt immediately begins querying your CMDB to correlate CIs with inventory resources.

Step 3: Map assignment groups to Draftt teams (optional)

If your Draftt user base matches your ServiceNow assignment groups, configure group mapping to translate CMDB assignment groups into Draftt team labels. In Integrations > Platform > ServiceNow > CMDB > Group Mapping, add entries for each assignment group you want mapped:
ServiceNow Assignment GroupDraftt Team Label
Platform Engineeringplatform-engineering
Data Engineeringdata-engineering
Security Operationssecurity-ops
Mapped groups appear in inventory filters and ownership views. Unmapped groups are shown with their raw ServiceNow name.

Step 4: Verify coverage

After the initial sync (typically completes within 30 minutes), go to Inventory and filter by Ownership Source: CMDB. This shows all resources where ownership was resolved from CMDB data. Compare this against the Orphaned filter to see how much of your unowned inventory CMDB resolved.

CI Correlation Logic

Draftt attempts to correlate each CI to a resource using a cascade of matching strategies:
  1. Cloud resource ID: Exact match on the cloud-native identifier (e.g., AWS instance ID, Azure resource ID)
  2. IP address: Match on the primary IP of the resource
  3. Hostname / FQDN: Match on DNS name or hostname
  4. Name pattern: Fuzzy match on resource name and CI name (used as a last resort, lower confidence)
Correlations are assigned a confidence level: High, Medium, or Low. Low-confidence correlations are surfaced for manual review in Settings > Integrations > ServiceNow > CMDB > Unverified Correlations.

Data Freshness

Draftt syncs with your CMDB on every scan cycle (by default, every 24 hours). CMDB changes (ownership reassignments, CI retirements, new CIs) are reflected in Draftt’s inventory at the next sync. Manual sync is available from Integrations > Platform > ServiceNow > CMDB > Sync Now.

Bidirectional Consideration

Draftt reads from CMDB but does not write back. If Draftt’s inventory discovers a resource with no corresponding CI in your CMDB, it surfaces this as an Uncatalogued Resource finding. Uncatalogued resources represent a CMDB hygiene gap: your change management system has a blind spot. These findings appear in the Security Hub and can be routed to your ServiceNow team as change requests via the ticketing integration.

Next Steps

  • Review Resource Ownership to understand how CMDB signals interact with other ownership sources
  • Check Security Hub to see how orphaned and uncatalogued resources are surfaced
  • Configure Ticketing to route uncatalogued resource findings to your CMDB hygiene team