The CMDB is supposed to be the authoritative source of truth for your IT environment. In practice, it often becomes a collection of competing truths, different discovery tools, integrations, and manual entries each contributing their own version of what a configuration item looks like. CMDB reconciliation is the process that resolves those conflicts and determines which data wins. Understanding how it works is essential for anyone responsible for ServiceNow CMDB accuracy, governance, or operational outcomes.
This article explains reconciliation from a governance and data quality perspective: why it exists, how source precedence works, what attribute-level control means in practice, and where most organizations run into problems.
Why Reconciliation Is Needed
Reconciliation exists because ServiceNow CIs are rarely populated by a single source. In most environments, discovery tools, service desk integrations, asset management feeds, and manual processes all write to the same CMDB tables simultaneously. Without a mechanism to manage those competing writes, the last update wins by default, regardless of whether it is the most accurate or trustworthy one.
Consider a common scenario: a discovery tool correctly identifies a server’s operating system version, but an integration from an external ITSM tool overwrites that field with outdated data pulled from a stale asset register. From a workflow perspective, the CI looks complete. From a quality perspective, it is wrong, and that error will propagate into incident routing, change advisory decisions, and any AI-driven automation that depends on that attribute.
CMDB reconciliation addresses this by introducing controlled rules that govern which source is allowed to set or update each attribute on a CI. Rather than letting writes happen freely, reconciliation enforces a defined order of trust. This is what separates a governed CMDB from one that simply accumulates data.
Source Precedence
Source precedence is the foundation of ServiceNow reconciliation. It defines a ranked hierarchy of data sources so that when multiple sources provide a value for the same CI attribute, the system knows which one to trust.
In ServiceNow, this is managed through the Identification and Reconciliation Engine (IRE). Each data source is assigned a precedence value, and when a CI is updated, the engine compares the incoming source’s rank against the source that last wrote the attribute. If the incoming source has equal or higher precedence, the update is applied. If it has lower precedence, the existing value is preserved.
Why Source Rankings Require Deliberate Design
The challenge is that default precedence settings are not tailored to any specific environment. An organization running multiple discovery tools alongside integrations from SCCM, Intune, or a third-party CMDB needs to make deliberate decisions about which source is authoritative for which type of data. A discovery tool may be the most reliable source for network configuration attributes, while an asset management system may be more accurate for financial or lifecycle data.
Getting source precedence right is not a one-time configuration task. As environments evolve and new integrations are added, precedence rules need to be reviewed and adjusted. Without that ongoing governance, the hierarchy drifts out of alignment with reality, and reconciliation starts producing results that no one intended.
Attribute-Level Control
Attribute-level control takes reconciliation a step further by allowing governance rules to be applied at the individual field level, rather than at the CI class level alone. This distinction matters significantly in complex environments.
A single CI class, such as a Windows server, may have dozens of attributes. Some of those attributes are best maintained by automated discovery. Others are more accurately managed by service desk staff or imported from a dedicated asset system. Treating all attributes the same way, applying one source precedence rule to the entire CI, produces the wrong outcome for at least some of those fields.
Practical Implications for CMDB Governance
Attribute-level control allows teams to specify, for example, that the IP address field on a server CI should only be written by ServiceNow Discovery, while the support group and environment fields can be maintained manually or by an ITSM integration. This level of granularity prevents authoritative data from being overwritten by less reliable sources, without blocking those sources from contributing the data they are actually good at providing.
In practice, implementing attribute-level control requires a clear understanding of the data model: which fields exist, which sources touch them, and what the intended owner of each field is. That design work is where most implementations fall short, not because the platform cannot support it, but because the governance model has not been defined clearly enough to configure it correctly.
This is an area where we see significant value in using Data Content Manager to enforce and audit attribute-level rules natively within ServiceNow, without scripting or custom development. The ability to design, apply, and review reconciliation governance from a single interface makes it far easier to maintain over time.
Common Governance Gaps
Even organizations that have invested in setting up reconciliation rules encounter recurring problems. These gaps are rarely caused by a lack of tooling, they are caused by a lack of ongoing governance around the configuration itself.
Rules That Were Never Fully Defined
The most common gap is incomplete rule coverage. Teams configure reconciliation for the most obvious CI classes and sources, then move on. Less common CI types, custom tables, or newer integrations get added to the environment without corresponding reconciliation rules. Those CIs then operate under default behavior, which often means last-write-wins, exactly the problem reconciliation was supposed to solve.
No Visibility Into What Is Actually Happening
Reconciliation operates in the background. Without active monitoring, it is difficult to know whether rules are working as intended, whether a new data source is overwriting authoritative values, or whether a CI class has been updated in a way that breaks an existing rule. Many teams only discover a reconciliation problem when a downstream process fails, a change is approved based on incorrect data, or an AI workflow produces an unexpected result.
Reconciliation Rules That Have Drifted
ServiceNow environments change. New discovery tools get added, integrations are updated, and CI classes are extended with custom fields. Each of those changes has the potential to invalidate existing reconciliation rules. Without a structured review process, the gap between the intended governance model and the actual configuration grows over time.
Addressing these gaps requires treating CMDB reconciliation as an ongoing governance discipline, not a configuration task that gets completed once. That means defining ownership of reconciliation rules, building visibility into how those rules perform, and reviewing them regularly as the environment evolves. The organizations that get the most out of their ServiceNow investment are the ones that treat CI data quality with the same rigor they apply to their processes and workflows.
If you are working through reconciliation challenges or want to understand how attribute-level governance can be applied in your environment, get in touch with us to see a demo of how Data Content Manager handles this natively within ServiceNow.
