IRE: Identification Rules vs Reconciliation Rules.

Match first, authorize updates second

IRE centralizes CMDB data integrity

The Identification and Reconciliation Engine processes supported incoming data before inserting or updating CIs. ServiceNow Discovery and Service Mapping use IRE-capable APIs, while integrations and Import Sets can also send payloads through supported IRE interfaces.

1. Validate the payload, class, attributes and relationships.
2. Identify the target CI using source identity or configured identification rules.
3. Decide whether an existing CI is updated or a new CI may be inserted.
4. Apply reconciliation and data-source controls to incoming attributes.
5. Commit permitted items and relationships, while returning decisions and errors.

Integration rule: inserting directly into CMDB tables can bypass centralized identification and reconciliation behavior. Use the supported IRE path for CI integrations unless current ServiceNow documentation explicitly requires another method.

Identification rules: which CI is it?

An identification rule applies to a CI class and contains an identifier with prioritized entries. Each identifier entry defines attributes or related items that can uniquely identify a CI. Stronger, more reliable identifiers should have higher priority.

A weak identifier such as a reusable display name can match multiple records or create duplicates when names change. Design rules around stable, populated identifiers and the correct CI class.

Reconciliation rules: which source may update?

After a CI is identified, reconciliation rules determine whether the incoming discovery source can update its attributes. This prevents one feed from unintentionally overwriting values governed by another authoritative feed.

• Static rules authorize sources and set priority for all or selected attributes on a class.
• A rule for a specific attribute is more specific than an all-attributes rule.
• A rule defined directly on a child class can refine a rule inherited from a parent class.
• Data Source History records which source last updated governed attributes after reconciliation is enabled.
• Dynamic rules use CMDB 360 data and take precedence over static rules for the same class attribute when configured.

Supporting rules solve different problems

Do not use a reconciliation rule to solve an insertion problem or an identification entry to decide attribute authority. Each control belongs to a different stage.

Worked scenario: Discovery and inventory feed disagree

Discovery finds a Windows server named APP-01. A third-party inventory integration sends the same serial number but an older operating-system value.

1. Both sources submit data through supported IRE processing for the correct server class.
2. The identification rule uses a stable identifier to match both payloads to one CI.
3. If no match exists, the data source rule determines whether that source may insert a new server CI.
4. Reconciliation authorizes Discovery to update operating-system attributes.
5. The lower-authority inventory update is rejected for those governed attributes rather than creating a second CI.
6. Other inventory attributes may still update if their reconciliation authorization permits it.
7. Data Source History and IRE output explain which source last updated or was denied.

The important separation is that correct matching does not automatically grant permission to update every field.

Troubleshoot duplicate CIs or rejected attributes

1. Capture the result: payload, source name, class, IRE response, operation and error details.
2. Verify class selection: the wrong class invokes the wrong identification hierarchy.
3. Trace identification: source key, identifier-entry priority, required attributes and related/dependent items.
4. Simulate safely: use the Identification Simulator or a no-commit identification API with representative data.
5. For duplicates: inspect de-duplication tasks, matching identifiers and feeds that bypassed IRE before merging anything.
6. For rejected updates: inspect discovery source, class inheritance, attribute-specific rules, source priority and Data Source History.
7. Check insertion policy: an IRE data source rule may intentionally allow updates but block new CIs.
8. Retest every source: rule changes can alter other Discovery, connector and integration payloads using the class.

Avoid the quick fix: weakening an identifier to make one payload match can join unrelated devices. Prove identifier uniqueness and data quality before changing production rules.

ServiceNow CSA practice checks

Frequently asked questions

Official ServiceNow references

Validate implementation against current ServiceNow documentation for the Identification and Reconciliation Engine, IRE components and processing, identification rules, reconciliation rules and duplicate-CI detection. Behavior varies by release, plugins and CMDB configuration.