ServiceNow CIS-DF: Identification and Reconciliation in CMDB
ServiceNow’s Identification and Reconciliation Engine solves two separate CMDB problems. Identification asks, “Does this incoming payload describe a CI that already exists?” Reconciliation asks, “If several sources know about the same CI, which source is allowed to update this attribute?” Treating these as one generic deduplication feature hides the architecture that keeps multi-source CMDB data trustworthy.
Current ServiceNow Australia documentation still defines IRE as the centralized framework for identification and reconciliation across CMDB and some supported non-CMDB tables. Identification rules, reconciliation rules, data-source rules, dependent relationship rules, de-duplication tasks, reclassification tasks, and the Identification Simulator all contribute to that framework. The goal is predictable record identity plus controlled source authority.
IRE is therefore one of the core platform mechanisms inside ServiceNow Platform Engineering.
Understand identification first
Identification determines whether an incoming CI matches an existing record or should create a new one.
IRE decisions use identifiers and rules defined per class and inherited through the CMDB hierarchy.
Good identifiers are stable enough to survive ordinary changes and specific enough to avoid merging distinct resources.
Design identifiers by CI class
A physical server, cloud instance, network appliance, application instance, and database may require different identity strategies.
Provider IDs, serial numbers, names plus domains, or compound attributes can each be appropriate depending on source reliability.
CMDB class design should define identifiers with the domain owner instead of applying one universal rule to every CI.
Test ambiguous and missing identifiers
Production feeds are rarely complete. Serial numbers can be absent, hostnames reused, cloud metadata delayed, and integrations can send partial payloads.
Use the Identification Simulator and controlled payloads to see how IRE behaves when fields are missing or conflicting.
Testing should include both false duplicate creation and false merging of distinct CIs.
Use reconciliation for attribute authority
Reconciliation rules specify which discovery source is authorized to update particular attributes and the priority among competing sources.
A Discovery source might own operating-system details while an asset or business system owns owner, criticality, or procurement data.
Without reconciliation, later writes can overwrite higher-quality information simply because they arrived last.
Use dynamic rules where the business requires them
ServiceNow supports static and dynamic reconciliation patterns, with documented precedence when both apply.
Dynamic logic can fit cases where authority depends on conditions rather than one permanent source ranking.
Use it only when the business rule is clear enough to test; complicated dynamic authority can become difficult to diagnose when an expected update is rejected.
Use data-source rules to restrict CI creation
IRE data-source rules can allow a source to update existing records while preventing it from creating new CIs for selected classes.
This is useful when a feed has valuable attributes but weak identity coverage.
CMDB governance should decide which integrations are trusted to expand the inventory and which may only enrich known records.
Model dependent CIs correctly
Some CIs can be identified only in relation to a parent or containing CI.
Dependent relationship rules define how those dependencies participate in identification and service construction.
CI relationships therefore influence identity as well as impact mapping in some parts of the model.
Interpret rejected updates as useful evidence
When reconciliation blocks a write, the event can indicate that the source is lower priority, that ownership changed, or that the rule is no longer aligned with reality.
Do not disable reconciliation simply because an integration reports rejected updates.
Review whether the rule or the source is wrong and preserve the intended authority model.
Make IRE part of integration design
Service Graph Connectors and well-designed CMDB ingestion paths use IRE because identity and authority are platform responsibilities.
Service Graph Connectors illustrate how third-party data can be transformed and then inserted through IRE rather than directly written into target tables.
For CIS-DF, IRE should be understood as the contract between incoming data and trusted CMDB state.
IRE rules should be versioned and reviewed like other shared platform configuration. A small identification change can alter whether thousands of incoming records create new CIs, update existing CIs, or generate duplicates. Test on representative payloads in sub-production before changing a high-volume class.
Source ownership should be documented with the rule. Administrators troubleshooting an update need to know why one source outranks another and which team can confirm the decision. A reconciliation priority without a business rationale can become historical configuration nobody wants to change.
Monitoring should include IRE errors, duplicate tasks, reclassification tasks, reconciliation rejections, and unusual changes in CI-creation volume. These signals can reveal a source contract or schema change before users notice inaccurate CMDB data.
IRE also reduces the temptation to create source-specific CI tables. Multiple sources can contribute to one shared CI when identity and authority are modeled correctly. That is a major platform advantage: operations sees one CI with governed attributes rather than several records that each represent one tool’s perspective.
The durable IRE model is class → identifier → source payload → match/create decision → attribute authority → relationship/dependency → lifecycle. When teams can explain each stage for a critical CI class, the CMDB becomes much easier to trust and troubleshoot.
Identification-rule design should begin with examples of “same CI” and “different CI.” For a Windows server, a hostname change after domain migration might still represent the same machine if a stronger serial or cloud ID is present. For a cloned VM, several attributes may match while the provider instance ID proves it is new. These examples help domain owners choose identifier order intentionally.
Identification rules can contain multiple identifier entries evaluated in sequence. Teams should understand how fallback identifiers behave when preferred fields are missing. A fallback that is too broad can merge distinct records precisely when the strongest identifiers are absent—when data quality is already weak.
Reconciliation priorities should reflect attribute-level authority. One source can be highest priority for IP addresses while another is highest for owner or lifecycle state. Modeling authority per attribute keeps the shared CI richer than choosing one “winner” source and discarding useful information from all others.
Dynamic reconciliation can support scenarios where authority changes by context, but it should remain rare enough to explain. When a help-desk analyst asks why an update was ignored, the platform team should be able to show the rule and condition that blocked it. Complex hidden priority logic undermines trust in the CMDB.
IRE data-source rules are also useful for migration. During onboarding of a new connector, allow it to update existing records while preventing it from creating new CIs until identity quality is proven. After monitoring shows stable matches, expand create authority deliberately. This reduces the blast radius of a new source.
Dependent identification deserves special attention for objects that only make sense in a parent context, such as application components or interfaces. The same local identifier can legitimately appear under different parent CIs. Relationship-aware identification prevents unrelated components from collapsing into one record.
IRE errors should be treated as source-quality signals. Missing required attributes, ambiguous matches, unsupported classes, or reconciliation conflicts often identify where the incoming payload or model is weak. Monitoring and categorizing these errors gives integration owners a concrete backlog.
Use the Identification Simulator before changing rules on a production class. Test known existing CIs, known new CIs, partial payloads, conflicting identifiers, and records from each major source. Capture expected outcomes so future rule changes can be regression-tested against the same cases.
Rule changes should include downstream checks for duplicate count, CI creation volume, rejected updates, relationship changes, and class distribution. A change that fixes one duplicate pattern can accidentally merge unrelated CIs or block legitimate updates. Compare before/after metrics during rollout.
The operational benefit of good IRE design is that teams can trust a CI as a shared record assembled from several sources. Incident, change, security, asset, and service-management processes then work from one identity rather than reconciling tool-specific records during every event.
Identification and reconciliation should also be included in source onboarding checklists. Before a new integration goes live, confirm target classes, identifiers, create authority, attribute ownership, dependent relations, expected volume, and error monitoring. This prevents the first production import from becoming the test.
Keep a rule-owner matrix so administrators can see which team approves changes to each critical class’s identification and reconciliation logic. Shared CMDB rules should never become ownerless platform configuration.
IRE troubleshooting should also distinguish identification failure from reconciliation denial. Identification decides which record the payload targets; reconciliation decides whether the source can change a field. A source can match the right CI perfectly and still be prevented from updating an attribute because a higher-authority source owns it.
Keep sample payloads from every major source and class. When the source changes a field name, identifier, or structure, those examples provide a fast way to reproduce IRE behavior and determine whether the platform rule or the incoming data caused the regression.
For platform maturity, treat IRE configuration as code-like shared infrastructure: controlled changes, tests, owner, release notes, and rollback. The CMDB identity layer deserves the same discipline as an API contract.