The Identification and Reconciliation Engine, or IRE, is central to keeping a ServiceNow CMDB consistent when data arrives from discovery, integrations, imports, and other sources. Identification decides which CI an incoming payload represents. Reconciliation decides which source is allowed to update particular attributes.<\/p>\n
For CIS-DF, candidates should be able to reason through what happens when multiple sources describe the same real-world object, why duplicate CIs appear, how authoritative-source logic protects good data, and why bypassing IRE can undermine CMDB health.<\/p>\n
Identification rules define the attributes used to locate an existing CI. The engine evaluates incoming data against those rules and attempts to find the record that represents the same real-world object. If it finds a valid match, the existing CI can be updated; if it does not, a new CI may be created.<\/p>\n
The quality of identifiers matters. A weak identifier such as a non-unique display name can create false matches, while an identifier that is rarely populated can create unnecessary new records. Rules should use attributes that are stable, available, and sufficiently unique for the class.<\/p>\n
A class can have more than one identification strategy. IRE evaluates identifiers according to configured priority and conditions. This supports environments where one data source provides a strong hardware identifier while another may provide only a different but still reliable set of attributes.<\/p>\n
Administrators should understand which rule is expected to match for each source and class. When duplicates appear, reviewing identification logic is often more productive than manually merging records one by one.<\/p>\n
After a CI is identified, reconciliation rules protect attribute ownership. One integration may be authoritative for serial number and hardware details, while another may own operational status or application-specific attributes. Reconciliation prevents a lower-quality source from overwriting a trusted value.<\/p>\n
This is essential in a multi-source CMDB. Without source precedence, the last integration to run could win regardless of data quality. Reconciliation makes update behavior intentional.<\/p>\n
It is easy to confuse the two because they are part of the same engine. Identification is about record identity. Reconciliation is about update authority. A system can identify the correct CI and still reject some incoming field changes because the source is not authoritative for those attributes.<\/p>\n
Exam scenarios often become simple once you ask which question is being asked. Duplicate creation suggests identification. A trusted value being overwritten suggests reconciliation.<\/p>\n
Modern CMDBs can receive the same CI from discovery, cloud connectors, endpoint tools, asset systems, and custom integrations. Source tracking helps ServiceNow maintain context about where data came from and supports multi-source views such as CMDB 360.<\/p>\n
Multi-source visibility is valuable because conflicting data is easier to understand when administrators can see each source\u2019s contribution. It also helps teams decide whether reconciliation rules reflect the intended authority model.<\/p>\n
Direct inserts and updates can bypass identification and reconciliation logic. That creates a path for duplicates and ungoverned attribute changes even when the CMDB has carefully designed rules.<\/p>\n
Integrations should use supported ingestion patterns that invoke IRE. A custom integration that ignores the engine becomes a permanent exception that administrators must compensate for later.<\/p>\n
When two records represent the same real-world object, the root cause may be missing identifiers, changed source data, inconsistent normalization, or an integration that did not use IRE. Deduplication fixes the current records; identification fixes the process that created them.<\/p>\n
After remediation, teams should retest the same incoming payload to confirm it now matches the surviving CI. Otherwise the duplicate may reappear on the next import.<\/p>\n
An overly restrictive reconciliation rule can prevent legitimate updates, while a permissive rule can allow poor data to overwrite trusted attributes. Source authority should be based on the real ownership of the data.<\/p>\n
Governance teams should review these rules as integrations change. A source that was once authoritative may be replaced, and new cloud or SaaS sources may introduce attributes the original design did not consider.<\/p>\n
When IRE behavior is surprising, inspect the class, identifier inputs, rule priority, source identity, and reconciliation decision. Determine whether the payload matched zero, one, or multiple records and which attributes were accepted or rejected.<\/p>\n
This method separates identity problems from source-authority problems. It also avoids the common mistake of changing several rules at once and losing the ability to tell which change actually fixed the issue.<\/p>\n
CI identity is only part of the model. Integrations often create or update relationships as well. If source systems use different semantics or relationship directions, the CMDB can become inconsistent even when CI identification works correctly.<\/p>\n
Teams should define which sources own important relationships and validate that their payloads align with the CSDM and service-model design. Relationship quality is essential for dependency maps and impact analysis.<\/p>\n
Duplicate trends, missing identifiers, and recurring reconciliation conflicts can reveal weaknesses in the design. A reduction in duplicate creation after a rule change is a stronger success measure than simply clearing the existing duplicate queue.<\/p>\n