ServiceNow CMDB data can arrive from Discovery, Service Graph Connectors, integrations, imports, security products, cloud platforms, and manual processes. If every source is allowed to insert and overwrite configuration items independently, the CMDB quickly accumulates duplicates and conflicting attributes. The Identification and Reconciliation Engine, or IRE, provides the control layer that determines whether an incoming record represents an existing CI and which sources are authorized to update particular attributes.
The current ServiceNow Certified Implementation Specialist – Data Foundations blueprint centers on operationalizing CMDB and CSDM. IRE is foundational because good service modeling depends on stable CI identity. Discovery can collect excellent technical data, but without correct identification and reconciliation that data can fragment into duplicate records or overwrite more authoritative values.
Separate discovery from identification
Discovery determines what exists and collects attributes and relationships from the environment. Identification answers a different question: does this incoming object match an existing CI, or should a new CI be created?
Keeping the concepts separate prevents a common misunderstanding that a discovery tool’s native identifier automatically defines enterprise identity. ServiceNow uses identification rules or source-provided unique identifiers to decide whether records represent the same CI.
Design identification rules around stable identifiers
Identification rules use attributes or related values that should uniquely identify a CI class. Good identifiers are stable across normal lifecycle changes. Hostname alone, for example, may be insufficient if names can be reused or changed.
Evaluate collisions and missing values before deploying a rule broadly. A weak rule can merge unrelated infrastructure, while an overly strict rule can create duplicates whenever one identifying field is absent.
Understand dependent identification
Some CI classes cannot be identified reliably from their own attributes. They are identified through relationships to another CI, such as an application component that depends on a host or service context. Dependent relationship rules express this structure.
This is especially important for service topology because correct dependency information supports both CI identity and the construction of application service maps.
Use reconciliation to protect authoritative attributes
Once a CI is identified, multiple sources may still provide different values for the same attribute. CMDB 360 and multisource reconciliation can help explain competing source values; reconciliation rules determine which sources are allowed to update which attributes, often with priority or authority boundaries.
A cloud connector may be authoritative for cloud account identifiers while an asset process owns financial fields and Discovery owns runtime details. Without reconciliation, the last writer can overwrite correct values simply because it ran later.
Use data-source rules to limit untrusted insertion
ServiceNow supports IRE data-source rules that can prevent a source from creating new CIs for a class while still allowing it to update existing records when appropriate. This is useful for integrations that provide supplemental attributes but should not define the existence of a CI.
Source trust should be explicit. If every integration can create every class, CMDB growth becomes difficult to control and duplicate prevention becomes harder.
Route integrations through IRE
Custom imports that bypass IRE can create records without identification and reconciliation controls. Use supported ingestion paths that invoke IRE so duplicate prevention and source authority are applied consistently.
The broader principles of infrastructure inventory management apply: inventory quality depends on stable identity and controlled updates, not simply on collecting more records.
Use de-duplication as remediation, not normal operation
IRE reduces duplicate creation, but existing duplicates or rule mistakes may still require de-duplication tasks. Merge carefully because relationships, history, incidents, and source identifiers may be distributed across the competing records.
After cleanup, fix the identification rule or source behavior that produced the duplicates. Repeated de-duplication without source correction is a sign that the operating model is incomplete.
Test rule changes with real source combinations
Identification and reconciliation rules can affect many integrations at once. Test changes with representative payloads from Discovery, connectors, imports, and custom sources. Include missing identifiers, conflicting attributes, and class changes.
Document expected outcomes before deployment: which CI should match, whether a new CI should be created, and which source should win each contested attribute. This turns IRE behavior into testable policy rather than tribal knowledge.
IRE outcomes are useful data-quality signals. Track duplicate creation, unmatched records, reclassification tasks, reconciliation blocks, and source-specific error patterns. Sudden changes can reveal an upstream integration modification or a broken rule before CMDB Health scores deteriorate broadly.
Use change-management discipline for significant IRE changes because one rule can alter how thousands of future records are created or updated.
Make CI identity a governed contract
For each critical class, document identifiers, authoritative sources, attribute ownership, and exception handling. Platform teams, discovery engineers, integration developers, and service owners should share the same contract.
The ServiceNow CMDB is most reliable when identity is deterministic and source authority is deliberate. Discovery tells the platform what it sees; IRE decides how that evidence changes the governed configuration record.
Identification rules should be class-specific because what uniquely identifies a server is different from what identifies a database instance, network interface, application, or cloud resource. Reusing one identifier pattern across unrelated classes creates false matches or duplicate growth.
Identifiers should survive normal operational changes. IP address is often a weak primary identifier because DHCP, failover, and cloud redeployment can move addresses. Serial numbers, cloud resource IDs, or source-specific immutable identifiers are usually stronger where available.
Composite identifiers can improve reliability when no single field is stable enough. A combination such as name plus namespace or host plus instance identifier may distinguish resources correctly. Document ordering and fallback behavior so administrators know which attribute set IRE tries first.
Source-native identifiers can help avoid expensive matching, but they should not create an unreviewed parallel identity system. Understand whether the identifier is globally unique, unique only inside one account, or reusable after deletion.
Reclassification is another IRE concern. A CI may initially be discovered as a generic class and later receive evidence that it belongs to a more specific class. Reclassification rules should preserve identity while moving the record into the correct model.
Attribute authority should be granular. One source might be best for operating-system version while another owns business criticality or support group. Reconciliation rules can protect individual attributes rather than declaring one integration authoritative for the entire CI.
Data-source priority should reflect freshness and trust. A high-priority source that runs monthly may not be appropriate for an attribute another reliable source refreshes daily. Authority decisions should combine semantic ownership with update behavior.
Discovery-source labels should remain stable. If an integration changes its source name unexpectedly, reconciliation can treat it as a new source with different permissions. Version integration changes carefully and test how IRE recognizes the source identity.
IRE data-source rules can block insertion from supplemental sources while still allowing updates to known records. This pattern is useful when one feed has good vulnerability or ownership metadata but should not decide that a new server exists.
Payload testing should include collision cases. Send two records that share a weak identifier but represent different objects, and two records that represent the same object with different optional attributes. The expected result should be understood before the rule reaches production.
Bulk imports can generate high-volume duplicate or reconciliation problems quickly. Use staging, small validation batches, and reconciliation monitoring before allowing a new integration to process the full environment.
Duplicate CIs can also expose problems in class selection. Two sources may discover the same object in different classes, making a straightforward identifier match impossible. Align data-source class mapping with the CMDB class model before blaming IRE itself.
Relationship identification deserves equal care. Dependent CIs can rely on parent context, and incorrect parent relationships can cause the same child object to appear as several distinct records. Test dependent-class behavior with realistic service topology.
Operational dashboards should separate blocked updates from actual errors. Reconciliation intentionally prevents lower-authority sources from overwriting protected attributes; that can be a successful control, not a defect. Alert only when the pattern indicates an unexpected source conflict.
CMDB identity is ultimately a contract between discovery, integration, platform governance, and service ownership. When the contract is explicit, IRE becomes predictable: incoming evidence resolves to one CI, authorized sources update only their fields, and duplicates become exceptions instead of normal operating noise.
Identification-rule order matters when a class has several possible identifier sets. Put the strongest, most reliable identifiers first so weaker fallback combinations are used only when better evidence is missing.
Fallback identifiers should be evaluated for collision risk. A hostname plus domain may work well in one environment but collide after mergers, lab reuse, or overlapping cloud accounts. Test historical data before standardizing a fallback.
When a source supplies a trusted native identifier, store enough context to know which source namespace it belongs to. The same numeric ID can be valid in two different cloud accounts or management systems without representing the same CI.
Data-source rules can also help during phased migrations. A new connector may initially be allowed to update known records but blocked from creating new ones until its class mapping and identifier quality are proven.
Reconciliation priorities should be documented per attribute category. Technical runtime fields, asset information, ownership, business criticality, and lifecycle status often have different authoritative systems.
Priority alone is not enough when values expire. If the highest-priority source stops updating, teams need a process for deciding whether a lower-priority source may take over. Source-health monitoring should therefore be linked with reconciliation design.
IRE errors should be grouped by root cause. Missing required identifiers, invalid class mappings, blocked source authority, payload format problems, and duplicate candidates require different remediation teams.
Bulk de-duplication should be tested with relationship-heavy CIs. Merging two records can affect service maps, historical incidents, vulnerabilities, assets, and custom references. Validate downstream consumers before applying the merge broadly.
Discovery schedules should align with the volatility of the class. Cloud instances may change rapidly, while network appliances or facilities equipment change less often. Update frequency affects freshness expectations and the time available to detect duplicate or stale data.
CI class selection should be governed centrally enough to avoid every integration inventing its own interpretation. A source that maps a database server to a generic computer class can prevent correct dependent identification and service relationships later.
IRE testing can use synthetic payloads that isolate one rule at a time. This makes it easier to validate identification order and reconciliation outcomes before integrating the complexity of a live connector.
Change windows for IRE rules should account for data volume. A small rule change can affect every subsequent discovery payload immediately. Monitor duplicate and reconciliation metrics closely after deployment and keep rollback instructions ready.
Source-specific ownership is also useful for incident routing. When reconciliation blocks an unexpected update, the source owner should receive the evidence rather than the CMDB team manually deciding which value is correct every time.
A mature CMDB treats identification and reconciliation as policy encoded in the platform. That policy says what makes a CI unique, which sources may create it, who owns each attribute, and how competing evidence is resolved. Clear policy is what keeps discovery scale from turning into data chaos.
Attribute reconciliation should include clear exception handling. If a lower-priority source contains a value that is known to be correct during an outage of the preferred source, operators need an approved process for temporary override rather than ad hoc direct edits.
Identification rules should be reviewed when infrastructure patterns change. Containerization, cloud migration, autoscaling, and managed services can replace long-lived servers with ephemeral resources whose old identifiers no longer remain stable enough for matching.
Integrations should log IRE responses and record identifiers so failed or unexpected matches can be traced back to the exact source payload. Without this evidence, teams are forced to infer why a record merged or duplicated after the original ingestion event is gone.
For business-critical classes, define a maximum acceptable duplicate rate and a response threshold. A small ongoing duplicate rate can become a large operational problem over time, especially when every duplicate receives incidents, vulnerabilities, and relationships independently.
Review identification and reconciliation metrics after every new connector launch. A spike in duplicate candidates or blocked writes is often the earliest evidence that the new source’s identifiers, class mapping, or authority model does not align with the existing CMDB contract.
When an integration is retired, remove or disable obsolete source rules so historical authority settings do not confuse future sources that take over the same attributes.
IRE quality improves when source onboarding, rule testing, and operational monitoring are one continuous process rather than separate projects handled by different teams with no shared feedback loop.
Use source onboarding checklists that require sample payloads, class mappings, identifier evidence, reconciliation ownership, and rollback procedures before production ingestion begins. This creates a repeatable standard for every new connector instead of relying on the experience of one CMDB administrator.
Periodically audit which sources are actually winning each important attribute. Rules may remain configured for a legacy source even after a newer integration becomes the practical authority. Effective governance depends on observed behavior as well as documented intent.
Keep an IRE decision log for major classes so administrators can see why particular identifiers and source priorities were chosen. This reduces accidental rule changes when new integrations are added years later.
Review the log whenever a new discovery source changes the evidence used to identify that class.