CMDB in ServiceNow: What It Is, How It Works, and Why It Keeps Breaking

// Query CI relationships
var gr = new GlideRecord('cmdb_rel_ci');
gr.addQuery('parent', serverCiSysId);
gr.addQuery('type.name', 'Runs on::Hosted by');
gr.query();
while (gr.next()) {
    gs.log('Application: ' + gr.child.getDisplayValue() + ' runs on this server');
}

// Get all active Linux servers
var gr = new GlideRecord('cmdb_ci_linux_server');
gr.addEncodedQuery('operational_status=1^install_status=1');
gr.query();
while (gr.next()) {
    gs.log(gr.getValue('name') + ' | ' + gr.getValue('ip_address'));
}

// Count CIs by class — use GlideAggregate
var ga = new GlideAggregate('cmdb_ci_server');
ga.addEncodedQuery('operational_status=1');
ga.addAggregate('COUNT', 'sys_class_name');
ga.groupBy('sys_class_name');
ga.query();
while (ga.next()) {
    gs.log(ga.getValue('sys_class_name') + ': ' + ga.getAggregate('COUNT', 'sys_class_name'));
}

CMDB population strategies

Discovery is the primary mechanism for auto-populating the CMDB with infrastructure data — servers, network devices, storage, applications. Discovery uses MID Servers to probe the network and populate CI records. For non-discoverable assets — hardware without network connectivity, software licensed by count, business services — manual population via Import Sets from authoritative data sources (SCCM, JAMF, a spreadsheet, an ITSM tool) is the standard alternative. The goal is a single authoritative source per CI type, not multiple competing data feeds writing to the same CI records.

CI relationships and the CMDB relationship model

// Query CI relationships programmatically
var rel = new GlideRecord('cmdb_rel_ci');
rel.addQuery('parent', serverSysId);
rel.addQuery('type', 'Runs on::Runs');
rel.query();
while (rel.next()) {
    var childCI = rel.getValue('child');
    gs.log('Application running on server: ' + rel.getDisplayValue('child'));
}

Relationships between CIs are stored in the cmdb_rel_ci table. The Relationship Type (cmdb_rel_type) defines what kinds of relationships are valid. Common relationships: Runs on (application to server), Hosted on (logical to physical), Contains (rack to device), Depends on (service to infrastructure). Building a complete relationship map is what turns a list of CIs into a true CMDB that enables impact analysis and change risk assessment.

CMDB Health and data quality

The CMDB Health dashboard (available in the CMDB application) scores your CMDB on three dimensions: Completeness (are required fields populated?), Compliance (do CIs meet defined policies?), and Correctness (are discovery data and manual data consistent?). Regularly reviewing CMDB Health metrics and acting on low scores is the operational practice that keeps a CMDB useful over time. A CMDB that was accurate at implementation and never maintained becomes a liability rather than an asset within 12-18 months in active environments where infrastructure changes frequently.

Related: ServiceNow Discovery · MID Server · Import Sets · ACL security · SLA management

CMDB for change management and impact analysis

The CMDB's value in change management is in impact analysis — understanding which services, users, and dependent systems are affected by a proposed change before executing it. This requires relationships to be populated accurately. A server CI with no relationships to the applications running on it cannot tell you which service teams to notify before maintenance. Building this relationship fabric — through Discovery, manual documentation, and integration with application portfolio tools — is what transforms the CMDB from a hardware inventory into a true service map. The ServiceNow Change management module uses CMDB relationship data to surface the "Impacted Services" field on Change Request records. When this works well, it prevents outages caused by changes that the change manager did not realise were affecting critical services. When the CMDB relationships are incomplete, the Change module cannot help and impact analysis falls back to tribal knowledge — which is unreliable and unscalable.

Production deployment and operational considerations

Deploying and maintaining any ServiceNow capability in production requires thinking beyond initial configuration. Consider monitoring: what alerts will tell you when something is not working as expected? Consider capacity: as data volumes grow, will this configuration scale appropriately? Consider documentation: will the next admin or developer who touches this understand what you configured and why? ServiceNow implementations that start well-documented and monitored stay well-configured over time. Those that are dep

CMDB class hierarchy — what to know

The CMDB is built on a class hierarchy rooted at the Configuration Item (cmdb_ci) table. Every CI type extends this root table either directly or through intermediate classes. Servers extend cmdb_ci_computer, which extends cmdb_ci. Applications extend cmdb_ci_appl. Network devices extend cmdb_ci_netgear. Understanding this hierarchy matters for two reasons: queries on a parent class (cmdb_ci_computer) return all records in child classes (Linux servers, Windows servers, virtual machines), and fields defined on a parent class are inherited by all child classes. When building reports or queries against CMDB data, query the most specific class that covers your scope rather than the root cmdb_ci table — the root table has millions of records in large implementations.

CMDB governance programme

A CMDB without a governance programme degrades over time. Establish: an authoritative data source for each CI type (Discovery for servers, JAMF for Macs, SCCM for Windows endpoints — one source of truth per type, not multiple competing feeds). A regular accuracy audit — quarterly sampling of 50 random CIs and verification that the record matches the physical/virtual reality. A lifecycle process for decommissioned assets — automated or manual process to retire CI records when assets are decommissioned. An owner for each CI class — someone accountable for the accuracy of that class of data. Without these governance elements, even a correctly configured CMDB loses accuracy over 12–18 months in active environments.

CMDB Health Metrics and Ongoing Governance

A CMDB that was accurate at launch degrades over time without active governance. The platform provides CMDB Health dashboards that track completeness (what percentage of CIs have required fields populated), compliance (what percentage meet defined standards), and correctness (what percentage have been confirmed accurate within a defined window). These health metrics should be reviewed at a regular cadence — monthly for most organisations — and assigned ownership: specific teams own specific CI classes and are responsible for the health scores in their domain. Connecting CMDB health to business outcomes (showing that accurate CMDB data reduces incident resolution time and improves change success rates) creates the organisational motivation needed to sustain governance beyond the initial implementation.

CMDB for Change Management

The CMDB's value in ITSM is most immediately visible in Change Management. A Change Record that references an accurate CMDB CI provides the change advisory board with information about the affected service's relationships — which other CIs depend on it, which services it supports, which customers are affected. Without accurate CMDB data, change impact assessment is based on institutional knowledge and educated guesses, which explains why many change management processes fail to catch downstream impacts. The connection between CI accuracy and change success rates is measurable: track the percentage of changes where CMDB relationship data was used in impact assessment alongside the change failure rate for those changes versus changes without CMDB-informed assessment. This correlation, presented to leadership, is the most effective argument for CMDB governance investment.

CI Relationships and Dependency Mapping

Individual CI records have limited value in isolation. The CMDB's power emerges from the relationship layer — knowing that Application Server A depends on Database Server B, which runs on Physical Host C, enables impact analysis that flat CI lists cannot support. ServiceNow uses the cmdb_rel_ci table to store typed relationships between CIs: "Runs on," "Depends on," "Connects to," "Hosted on." Relationship types matter for impact analysis queries: a "Depends on" relationship means the upstream CI's outage impacts the downstream CI, while "Connects to" implies communication without strict dependency. Populate relationships through Service Mapping where available (it discovers relationships automatically by tracing application traffic), and through manual entry or import for relationships that automated discovery cannot detect. A CMDB with accurate relationships enables change impact analysis, incident prioritisation, and root cause analysis at a quality that flat CI inventories simply cannot match.