When multiple tools describe the same infrastructure, the CMDB has two different problems to solve. First, it must decide whether an incoming record refers to a CI that already exists. Second, once the correct CI is found, it must decide whether the incoming source is allowed to update the attributes it supplied. ServiceNow separates those problems into identification and reconciliation.
The current CIS-DF (CMDB and CSDM) scope expects practitioners to understand that data integrity depends on those controls. ServiceNow’s Identification and Reconciliation Engine (IRE) provides the framework: identification rules prevent duplicate representations of the same CI, while reconciliation rules determine which sources can update which data.
The phrase “how the right CI wins” is useful only if we define winning correctly. The goal is not to make one source globally dominant. The goal is to select the correct existing CI and preserve the most authoritative value for each controlled attribute.
Identification happens before authority matters
Imagine two sources reporting the same server. Source A calls it by hostname and serial number. Source B supplies a cloud instance identifier and IP address. Before ServiceNow can reconcile attributes, it must determine whether both payloads refer to one CI or two different CIs.
Identification rules encode the attributes that can uniquely identify objects in a class. If the rule finds an existing match, IRE can update that CI. If not, and policy permits creation, a new CI may be inserted.
A weak identification rule creates duplicates. An overly broad rule can do something worse: merge two real objects into one record. The design must therefore reflect how identity behaves for that class in the real environment.
Good identifiers are stable, available, and truly discriminating
A candidate identifier can look unique in a sample and fail at scale. Hostnames can be reused. IP addresses can change. Serial numbers may be missing or formatted inconsistently. Cloud identifiers may be stable only within a provider or account context.
Identification design should ask three questions. Is the value stable across the CI lifecycle? Is it available from the sources that need to identify the CI? Does it uniquely distinguish objects within the intended scope?
When one attribute is insufficient, a rule can use a combination. The important point is that the rule describes identity rather than convenience.
Dependent CIs make context part of identity
Some objects cannot be identified reliably without the context of another object. Their identity depends on a parent or hosting relationship. ServiceNow supports dependent relationship rules for these cases.
This is important because technical systems contain many repeated local names. A database instance name, interface, or application component may only be unique within a particular host or parent service. Treating the child as globally unique creates collisions; treating every appearance as new creates duplicates.
Dependency-aware identification preserves the real structure of the environment while still giving the engine deterministic rules.
Reconciliation begins after the CI is known
Once the incoming payload is matched to the correct CI, the next question is authority. Several sources may legitimately know different things about the same record. A discovery source may observe operating-system details. An asset process may control ownership or lifecycle information. A cloud connector may know provider-specific attributes.
Reconciliation rules determine which source can update which attributes and with what priority. This prevents a lower-authority source from overwriting data maintained by a more trusted process.
The key mental model is attribute-level authority. “Source A wins” is usually too crude. Source A may be authoritative for one set of fields and not another.
Without controlled reconciliation, the most recent integration can make the CMDB appear unstable. A value changes after discovery, changes back after an asset import, and changes again after a manual update. Users see inconsistency; administrators see competing jobs.
Last-write-wins behavior is attractive because it requires little design. It is weak because timing is not the same thing as authority. The source that ran most recently is not necessarily the source that knows the truth.
Reconciliation replaces timing with policy. That policy should be documented and owned so teams understand why a particular value survives.
Data source rules control who may create records
A source can be useful for enriching existing CIs without being trusted to create new ones. ServiceNow data source rules can restrict insertion for selected classes while still allowing updates under controlled conditions.
This is valuable when a secondary feed contains incomplete identity information. Allowing it to create CIs could generate duplicates, but blocking it entirely would discard useful attributes. Separating create authority from update authority produces a safer integration boundary.
The design question becomes: what evidence must a source provide before it is allowed to introduce a new object into the CMDB?
As new evidence arrives, the platform may learn that a CI belongs in a more specific or different class. Reclassification can be legitimate, but it changes semantics and can affect relationships, rules, and downstream behavior.
A mature CMDB treats class changes as controlled state transitions. Teams should understand what triggers reclassification, which rules apply after the move, and whether integrations still provide compatible identity data.
This matters because the “same CI” can retain identity while its classification becomes more accurate. Identification and class design must cooperate rather than compete.
Use the simulator and trace evidence before changing rules
When IRE behavior looks wrong, changing the rule immediately can create a wider problem. A safer approach is to reproduce the payload, inspect the identification path, confirm the source, and test the rule logic with controlled evidence.
The troubleshooting questions are concrete: Which class did the payload target? Which identification rule evaluated? What attributes were available? Was a match found? Which reconciliation rule applied? Which source had authority? Was an attribute skipped because a higher-priority source already controlled it?
This disciplined trace is much safer than editing a CI manually and waiting to see whether the value returns.
Duplicate cleanup should lead to rule improvement
De-duplication tasks are necessary when duplicates already exist, but cleanup alone is not success. If the identification logic or source behavior remains unchanged, the duplicates will return.
The remediation process should connect the duplicate to its mechanism. Was the identifier missing? Did two sources format it differently? Did a source bypass IRE? Was the class wrong? Did a dependent CI lack parent context?
This mirrors the broader configuration-management principle that durable quality improvements change the control that produces data rather than repeatedly repairing individual records.
Authority should match organizational responsibility
Technical reconciliation rules encode business decisions. Declaring one source authoritative for ownership, lifecycle, location, or technical state is effectively assigning decision rights to the process behind that source.
That is why reconciliation design belongs in governance, not only integration engineering. Domain owners should agree on where truth lives, how exceptions are handled, and how a change in source strategy affects the CMDB.
A rule can be perfectly configured and still be organizationally wrong if the chosen source is not accountable for the data it controls.
The right CI wins when identity and authority agree
For CIS-DF candidates, the reusable sequence is: identify the object, find or create the correct CI under controlled rules, then reconcile each incoming attribute according to source authority. Identification answers “which record?” Reconciliation answers “which value?”
Within the ServiceNow data foundation, this separation is powerful because it lets many sources contribute without turning the CMDB into a race between integrations. It also gives practitioners a precise troubleshooting path when records duplicate or values appear to change unexpectedly.
The right CI does not win because one tool is globally trusted. It wins because the platform can prove that the incoming data refers to the correct object and that the surviving values came from sources authorized to own them.
Identification and reconciliation behavior becomes harder to reason about when class hierarchies and inherited rules are involved. A child class may inherit behavior from a parent unless more specific rules exist. That can be helpful because common logic does not need to be duplicated, but it also means a change high in the hierarchy can affect more CIs than the administrator expects.
Before changing a parent-level rule, teams should identify the descendant classes that rely on it and test representative payloads from each important source. A fix for one class can accidentally alter matching or authority elsewhere. Controlled simulation and regression examples make these dependencies visible.
Reconciliation often works by refusing a write that is not authorized. From a data-integrity perspective, that can be exactly correct. From an operational perspective, repeated skipped updates may indicate that a source owner believes it controls an attribute that governance assigned elsewhere.
Patterns of rejected or ineffective updates should therefore be reviewed. They can reveal obsolete integration assumptions, duplicated data ownership, or a migration that never updated the reconciliation model. The engine protects the record, but governance still needs to resolve the organizational disagreement behind the repeated conflict.
A useful control is to keep a small library of representative payloads for important CI classes and sources. Those examples become regression tests whenever identification or reconciliation logic changes. Instead of relying on memory, the team can prove that known matches, non-matches, and source-authority outcomes still behave as intended after the rule change.
