Configuration item relationships are the connective tissue of a well-functioning CMDB. They tell you what depends on what, which services are affected when something changes, and how your infrastructure actually behaves in practice. Yet in most ServiceNow environments, relationship data gets far less attention than the CIs themselves. Fields get populated, discovery runs, and records accumulate – but the relationships between them are often incomplete, stale, or simply wrong. The result is a dependency map that looks convincing until you actually need to rely on it.
Measuring CI relationship quality requires a different lens than measuring attribute completeness. A CI can have every field filled in and still be useless if its upstream and downstream connections are missing or misconfigured. This article breaks down what good CMDB relationship quality looks like, which dimensions matter most, how to put concrete metrics around them, and how to build the review habits that keep relationship data trustworthy over time.
What Good CI Relationships Look Like
A high-quality CI relationship is accurate, purposeful, and maintained. It reflects a real dependency or connection that exists in your environment, it uses the correct relationship type, and it points to CIs that are themselves active and valid. When these conditions are met, relationship data becomes genuinely useful for impact analysis, change management, and service mapping.
Good relationships also follow consistent patterns. In a well-modeled CMDB, you would expect application CIs to have relationships to the servers or containers they run on, those infrastructure CIs to relate to network devices or cloud regions, and everything to connect upward to a business service through a defined CSDM structure. Gaps in that chain are not neutral – they mean that automated impact analysis will return incomplete results, and that AI-driven workflows will make decisions on partial information.
Relationship Types Matter
ServiceNow provides a rich set of predefined relationship types: Runs on, Hosted on, Depends on, Connects to, and many others. Using the wrong type is a quality problem even when the direction and endpoints are correct. A relationship recorded as “Connects to” when it should be “Depends on” will produce incorrect results in downstream processes like outage impact assessment or root cause analysis. Consistent use of the right relationship types is a foundational quality criterion.
Direction and Symmetry
Relationship direction carries meaning. A server that hosts an application is not the same as an application that runs on a server – even though both describe the same physical reality, the directionality matters for how ServiceNow traverses the graph during service impact calculations. Checking whether relationships are pointing in the intended direction, and whether expected reciprocal relationships exist where the model requires them, is a practical quality check that is easy to overlook.
Core Quality Dimensions for CMDB Relationship Data
Relationship quality is not a single measure. It breaks down into several distinct dimensions, each of which can fail independently. Understanding these dimensions is the first step toward knowing what to actually measure.
Completeness
Relationship completeness asks whether the relationships that should exist actually do. For any given CI class, there are expected relationship patterns based on your data model. An application CI with no infrastructure relationships is almost certainly incomplete. A business service with no application CIs connected to it cannot support meaningful service impact analysis. Completeness is measured by comparing the actual relationship count and pattern against what your model defines as the expected minimum.
Accuracy
Accuracy addresses whether the relationships that do exist are correct. This includes checking that both endpoints are valid and active CIs, that the relationship type matches the actual dependency, and that the relationship was not created by a stale discovery run or a one-off import that no longer reflects reality. Orphaned relationships – those pointing to retired or deleted CIs – are a common accuracy problem that silently degrades CMDB reliability.
Currency
Relationship data ages. Infrastructure changes, applications are decommissioned, and services are restructured – but relationship records often persist long after the underlying reality has changed. Currency measures how recently a relationship was validated or confirmed, and whether it was created or last updated by a reliable source such as Service Graph Connectors or a governed discovery process, rather than a manual entry with no review date.
Consistency
Consistency looks at whether similar CI types follow similar relationship patterns across the CMDB. If half of your Linux servers have a “Hosted on” relationship to a hypervisor and the other half do not, that inconsistency signals either a data quality gap or a modeling ambiguity that needs resolution. Consistency checks are particularly valuable when multiple teams or discovery sources contribute to the same CI classes.
Practical Metrics for CI Relationship Quality
Translating these dimensions into measurable, reportable metrics is where most CMDB quality programs stall. The goal is to define metrics that are specific enough to act on, not just high-level scores that tell you something is wrong without pointing to where.
The following metrics provide a practical starting point for any ServiceNow environment:
- Relationship completeness rate by CI class: The percentage of CIs in a given class that have at least the minimum required number of relationships as defined by your data model. Track this per class rather than as a single aggregate.
- Orphaned relationship count: The number of relationships where one or both endpoints reference a CI in a retired, absent, or decommissioned state. This should be zero in a well-maintained CMDB.
- Relationship type accuracy rate: Spot-check or rule-based assessment of whether the relationship types in use match the intended semantic meaning for that CI class pairing.
- Stale relationship percentage: The proportion of relationships that have not been validated or updated within a defined threshold – for example, 90 days for discovery-sourced relationships or 180 days for manually created ones.
- Service coverage via relationships: The percentage of business services in your CMDB that have a complete, traceable dependency chain down to infrastructure CIs. This is a high-value metric for service owners and change managers.
- Relationship density variance: For CI classes where a typical relationship count is well understood, flag CIs that fall significantly below the average. An application with two relationships when the class average is twelve is worth investigating.
We use Data Content Manager to define and enforce these kinds of metrics directly within ServiceNow, without scripting. Rules are applied at the data model level, so deviations surface automatically rather than through periodic manual audits. This is particularly useful for relationship completeness checks, where the expected pattern varies by CI class and would be cumbersome to maintain in a spreadsheet or external tool.
Review and Ownership of Relationship Data
Metrics without accountability tend to stay as metrics. The final piece of a functioning CI relationship quality program is a clear review cadence and an ownership model that assigns responsibility for keeping relationship data accurate.
Ownership of relationship data typically needs to be shared. Discovery teams own the accuracy of automatically sourced relationships and are responsible for ensuring that discovery configurations produce the right relationship types and directions. CI owners – often application owners or service owners – are responsible for validating that the relationships on their CIs reflect current reality, particularly for manually maintained relationships or those that span organizational boundaries.
Review Cadence
A practical review cadence distinguishes between automated and manual relationships. Discovery-sourced relationships should be reviewed whenever discovery configurations change and audited on a quarterly basis for currency and accuracy. Manually created relationships warrant a shorter review cycle – monthly or at every change window that touches the relevant CIs. Business-service-level relationship completeness is best reviewed in advance of major change freezes or audit periods, when the cost of gaps is highest.
Making Reviews Actionable
The most effective reviews are not open-ended audits. They are structured around specific metrics and produce a defined output: a list of CIs or relationships that fail a given quality rule, assigned to the right owner, with a target resolution date. When review outputs are vague, remediation stalls. When they are specific – “these 14 application CIs in the ERP service have no infrastructure relationships and are owned by the platform team” – action follows more reliably.
Building relationship quality into the regular rhythm of CMDB governance, rather than treating it as a one-time cleanup exercise, is what separates organizations that maintain a reliable dependency map from those that rebuild it before every major incident or audit. The metrics exist to keep that rhythm honest.
If you want to see how these quality dimensions and metrics can be enforced directly in your ServiceNow environment, get in touch and we will walk you through it.
