What ServiceNow's IRE does when two sources disagree

When four tools report the same device, they will disagree — about the OS string, the model, sometimes the hostname itself. ServiceNow’s Identification and Reconciliation Engine handles this in two distinct stages, and most of the confusion comes from treating them as one.

Identification answers: is this the same CI I already have? It works through identifier entries — ordered sets of attributes, per class, that are treated as sufficient to recognise a thing. Serial number, then MAC, then name, for example. If an incoming payload matches on an identifier, it updates the existing record. If it does not, you get a new one.

Reconciliation answers a completely different question: this source wants to write this field — is it allowed to? Reconciliation rules say which data source is authoritative for which attributes on which classes.

The part that bites

If no reconciliation rule covers an attribute, the last writer wins.

That is not a failure state, it is the default. It means the value on the record reflects whichever integration happened to run most recently, which in practice is whichever one is scheduled latest. Nobody chose that, and nothing on the record says it happened.

So a CMDB with no attribute-level precedence does not have conflicting data — it has data that silently churns. The OS string flips back and forth on a weekly cycle and the quality report shows the field as populated throughout.

Duplicates are usually an identification problem, not a data problem

When people say their CMDB is full of duplicates, the cause is almost always that a source is sending payloads without any attribute the identifier rules can match on — so every run creates a new record. Fixing the identifier set upstream is the repair. Deduplicating the output is treating the symptom and it will regrow.

What to decide, in order

1. Which sources exist, and what each is actually good at. A scanner that reads hardware is not authoritative about who owns the device.
2. Identifiers per class, so the same thing resolves to the same record.
3. Precedence per attribute, not per source. Sources are good at different fields. A single global ranking is the most common shortcut and it misplaces most fields.
4. What happens when precedence has nothing to say — because that case will occur, and the answer should be a recorded decision rather than a scheduling accident.

The principle worth holding on to: which source owns which attribute is a decision someone should be able to defend, not a side effect of the job schedule.

How precedence is authored from the data itself, including per-class overrides and field-level rules, is in the source precedence documentation.