ServiceNow reconciliation rules decide which data source is permitted to write which attribute on a configuration item (CI). Identification decides which record an incoming payload belongs to. Reconciliation decides whose version of the truth survives once it gets there. Both run inside the Identification and Reconciliation Engine, back to back, and teams that have carefully tuned the first routinely leave the second untouched.
Nothing appears broken, which is the problem. What actually breaks is quieter: an operating system version that changes twice an hour, an owner field that resets overnight, a location that contradicts the service desk.
Worth separating properly, because the symptoms get confused constantly.
An identification failure produces two records where there should be one. You can see it. Somebody counts, or a duplicate report flags it, or an engineer opens the CI and finds no history on it.
A reconciliation failure produces one record with the wrong values in it. There is nothing to count. The record looks complete, it looks maintained, and every attribute on it is plausible. It is simply describing a different machine than the one in the rack.
Of the two, the second does more damage during an incident, because nobody has any reason to distrust it.
Three things: a CI class, a data source, and the list of attributes that source is authoritative for.
That is the whole model, and its simplicity hides the decision it forces you to make. You are not declaring a source trustworthy. You are declaring it trustworthy for specific fields. Horizontal discovery is excellent for operating system version and installed memory, and worthless for cost centre. Your human resources system is the reverse.
A source with no reconciliation rule covering an attribute is not blocked from writing it. That distinction is where most estates come unstuck.
Absent a reconciliation rule, the engine permits any source to write any attribute. The last write wins.
So the true owner of your operating system field becomes whichever integration happened to run most recently. That ordering is not stable. It shifts when a schedule changes, when a job runs long, when someone reruns a failed import. The field flips between values that are each individually defensible, and the record's accuracy depends on cron timing.
Teams often discover this after a platform upgrade, when job scheduling shifts slightly and a field that was reliably right for two years starts being reliably wrong.
When two sources both claim an attribute and both run on a cycle, the value oscillates.
The attribute damage is the visible part. The expensive part is downstream. Every one of those writes is an update to the CI record. The audit history fills with churn. Anything that keys off recent modification, such as a data quality report, a staleness metric, or a recently-changed view used during major incident triage, now treats a record that nobody touched as one of the most active items in the estate.
If you are running problem trend analysis over configuration data, this is the noise that buries the signal. And it compounds. The more sources you integrate, the more attributes have multiple claimants, and the more of your change history is machines arguing with each other.
There is no universal answer, but there is a reliable principle. The authoritative source is the one closest to the fact.
| Attribute type | Usually authoritative | Why |
|---|---|---|
| Technical state: operating system, memory, installed software | Horizontal discovery | It reads the machine directly |
| Cloud instance configuration | The platform's Service Graph Connector | The provider is the system of record |
| Lifecycle and financial: purchase date, cost centre, contract | Asset or finance system | Discovery cannot see any of it |
| Ownership and support group | Service management process, not a scanner | It is an organisational fact, not a technical one |
| Business criticality | Service owner, via governed process | No tool can infer it |
| Location | Depends on the estate; decide explicitly | Discovery infers it, facilities records assert it |
Work through this per class rather than globally. The right precedence for a virtual machine is not the right precedence for a network device or a database instance.
We saw the cost of skipping this on an estate running into the tens of millions of configuration items.
A cloud security posture tool had been designated the definitive source for cloud CIs. The reasoning was sound on its face, because the tool had the broadest visibility of anything in the environment, so it seemed like the natural authority. But it exposed no unique identifier for elastic compute instances that could correlate to records already in the CMDB, so every instance it imported created a duplicate of one horizontal discovery had already built.
The duplicates never reached the de-duplication queue, because the engine had never recognised the pairs as candidate matches in the first place. The report everyone relied on to catch exactly this showed nothing. It surfaced only when a cloud administrator noticed his instance count was double what his own console reported. By then changes were being raised against the wrong records, and every impact analysis run on those changes was wrong with them.
The fix was narrow. Stop taking compute instances from that tool, take them from the Service Graph Connector for Amazon Web Services instead, and leave the rest of the tool's data where it was. A source being excellent at its own job does not make it authoritative for your CMDB, and "definitive source" is a phrase worth refusing until somebody names the attributes it applies to.
Our two-week CMDB health baseline covers reconciliation as well as identification. In practice that means mapping every writing source against every attribute it currently touches, finding the attributes with more than one claimant, reading the audit history for oscillation, and producing a precedence matrix per class that names an owner for each field. The output is a scored report suitable for a change advisory board, which matters here because changing precedence is a governance decision as much as a technical one.
Where the question is broader, the data quality assessment measures against weighted critical success factors and measures, and the discovery and integration coverage review establishes what your estate view is missing. Both are scoped at the initial consultation against your requirements and your estate.
Two ways to start. Book a CMDB diagnostic call if you want a consultant to look at what you have, or book a meeting to talk through scope directly.
The engine uses the priority ordering on the rules. If the priorities are equal or ambiguous, you are back to timing determining the outcome, which is the situation reconciliation rules exist to prevent. Audit for duplicate claims rather than assuming the rules resolve it.
No. Reconciliation governs attribute values. Relationships between CIs are handled separately, which is why a correctly reconciled estate can still carry a dependency map that nobody owns.
Yes, and this is usually the right first move. Grant the source authority for the attributes it genuinely owns and it stops competing for the rest, without losing the data you wanted from it.
Read the audit history for the attribute on a sample of records. Alternating values on a regular cycle, with different update sources, is the signature. A data quality report showing high update volumes against low genuine change is the estate-wide version.
Usually, because it reads the machine. The exception is virtualised and cloud infrastructure, where the platform's own connector generally has better fidelity than an external scan, particularly for anything the hypervisor or provider controls.