ServiceNow Identification and Reconciliation Engine Explained

What the Identification and Reconciliation Engine Does

The Identification and Reconciliation Engine is a system component that matches configuration items discovered from different sources and identifies when multiple records represent the same physical component. When discovery tools scan your infrastructure, they gather information from different sources: active directory, network devices, applications, and monitoring systems. Each source might discover the same server using different identifiers: one system sees a MAC address, another sees a hostname, another sees an IP address. The IRE matches these records and creates a unified view of each component.

The IRE prevents duplication in the CMDB. Without matching and reconciliation, the same server might be represented as multiple separate configuration items. This duplication causes problems: incident assignments and change tracking become confused, capacity calculations are incorrect, and the CMDB does not reflect accurate infrastructure. The IRE creates unity across these different perspectives.

Where the IRE Lives in ServiceNow

The Identification and Reconciliation Engine is part of Discovery and CMDB management. It runs as a background process that evaluates discovered data and applies reconciliation rules. The rules define how to identify when multiple records should be merged or linked. Rules might specify that servers with the same hostname are the same physical server, or that network interfaces with the same MAC address belong to the same device.

The IRE maintains reconciliation history so that you can see how records have been matched over time. If the IRE incorrectly matches records, administrators can manually split them and update rules to prevent similar errors in future reconciliation cycles. This iterative refinement improves data quality continuously.

A Worked Example: Server Record Reconciliation

Active directory discovers a server with hostname app-server-01 and an IP address. The monitoring system discovers a server with the same IP address but has a different hostname because monitoring data has not been updated. A network discovery discovers a device with a MAC address matching the server’s network interface.

The IRE applies reconciliation rules and identifies that all three discoveries represent the same physical server. It creates a unified CMDB record that includes information from all three sources: the canonical hostname from active directory, the monitoring status from the monitoring system, and the network configuration from the network discovery. Subsequent discoveries and updates are matched against this unified record.

If the server is decommissioned, the IRE matches the decommissioning discovery to the existing record and updates the status. When a replacement server is deployed with a new IP address but the same hostname, the IRE recognises that this is a different physical server based on the IP address change and creates a new record.

Common Misunderstandings About the IRE

A frequent misunderstanding is thinking that the IRE eliminates the need for configuration item cleanup. The IRE matches records automatically, but poor data quality in source systems can still cause matching problems. If source systems are fundamentally inaccurate, the IRE cannot compensate. Improving source system accuracy is as important as having good reconciliation rules.

Another confusion is assuming that all discovered records are automatically reconciled. The IRE applies rules to identify matches, but reconciliation rules must be thoughtfully configured. If rules are too strict, matching records are not reconciled. If rules are too loose, unrelated records might be incorrectly matched. Finding the right balance requires tuning.

Some organisations incorrectly assume that the IRE produces perfect results without oversight. In reality, reconciliation processes should be monitored and occasionally manually reviewed. When records are reconciled incorrectly, administrators should understand the cause and update rules to prevent recurrence.

Configuring Reconciliation Rules

Reconciliation rules define matching criteria. A rule might specify that servers are the same if they have the same hostname, or the same IP address, or the same MAC address. Multiple rules can apply to the same record type, and the IRE evaluates all applicable rules when determining matches. The strength or confidence of a match can be weighted, allowing stronger matches to override weaker ones when conflicts occur.

Custom rules can be created for specific infrastructure components or organisational needs. Some organisations have naming conventions that make hostname matching reliable. Others use MAC addresses as the primary identifier. Rules should be based on what is reliable in your infrastructure.

Reconciliation rules should be reviewed and updated when infrastructure changes. If all servers are virtualized and MAC addresses change with new virtual machines, hostname-based matching might be more reliable than MAC-based matching. Periodic review of reconciliation rules ensures they continue to work well as infrastructure evolves.

Deciding which data source should win a conflict

The reconciliation engine does not decide truth on its own. It applies the identifiers and precedence rules you configure, so the first design task is ranking your data sources for each class of configuration item. A discovery scan is often strong for what is running on a host, while a financial asset register may be stronger for ownership and purchase details. Without an agreed ranking, two sources will keep overwriting each other’s attributes, and the record will change every time either source runs. The ranking should be set per attribute group where possible, not once per table.

How identifiers decide that two records are one item

Matching depends on identifiers, and identifiers are only as good as the attributes behind them. A serial number is strong for hardware but blank on many virtual machines. A hostname is common and reused, so it is weak on its own. Many failed reconciliations trace back to a class where the identifier set was copied from a default and never tested against real data. Test the identifier sets against a sample of known duplicates and known distinct items before you enable them in production, and keep a short note on why each identifier was chosen.

1. Pull a representative sample of each class, including retired items and items that were renamed.
2. Mark the pairs you already know are the same, and the pairs that look similar but are different machines.
3. Run the identifier set against the sample and count the false merges and the missed merges separately.
4. Adjust the identifier order or add a qualifying attribute, then repeat until both counts are acceptable to the service owner.
5. Only then enable the rule for the live class, and schedule a review after the first full discovery cycle.

Reading the reconciliation logs when a record looks wrong

When someone reports that a server has picked up another server’s software, start with the reconciliation history on the affected item rather than the discovery log. The history shows which source last touched each attribute and which identifier triggered the match. If the match was wrong, the common causes are a shared hostname in a cloned image, a load balancer name reused across environments, or an identifier that is blank on one source and therefore ignored on the other. Fix the cause in the rule, then repair the record, because correcting the record alone will be undone on the next scan.

Signs the engine is hiding a problem rather than solving one

A quiet reconciliation queue can be a warning sign. If the number of duplicate candidates falls sharply after a rule change without a matching drop in actual duplicates in the estate, the rule may be suppressing matches it should be raising. Compare the candidate count with an independent inventory check on a sample of hosts. Also watch for items that are never reconciled at all because their only source is a manual entry with no identifier. Those records look healthy in reports while drifting away from reality.

When to stop tuning rules and clean the source data

There is a point where further rule changes make things worse. If the same class keeps producing false merges after two rounds of identifier changes, the underlying source data is probably inconsistent. A cloud connector that writes a different hostname format from the on-premise scan can defeat any hostname rule. In that case, normalize the source values, or agree a naming standard with the teams that create the hosts, rather than adding a third exception to the rule set.

Checklist before you widen the scope

• Source precedence is written down for every governed attribute group, with a named owner for each source.
• Identifier sets have been tested against known duplicates and known distinct items.
• Someone can explain, for any reconciled item, which source supplied each value.
• A regular review of merge decisions is scheduled, with a person who can reverse a wrong one.
• Retired items are handled by a rule that marks them rather than deleting history.

Frequently asked questions about reconciliation outcomes

Can we run reconciliation only for servers and leave network devices alone?

Yes, and it is often the right first step. Start with the class where identifiers are strongest and sources agree most often, prove the outcome, then widen. Running every class at once makes it hard to tell which rule caused a problem.

Why does a manual correction get reverted after the next scan?

Because the discovery source still holds the value you overwrote, and it has higher precedence for that attribute. Change the precedence for that attribute group, or correct the value at the source, rather than in the CMDB record.

What is the difference between a duplicate and a stale record?

A duplicate is two live records describing one real item. A stale record is one item that no source has seen for some time. Reconciliation can merge duplicates, but stale records need a retirement rule with an owner, otherwise they accumulate in reports.

Should business owners be able to edit reconciled attributes?

Only the attributes they are the authoritative source for. Give them edit rights on those fields and read-only views elsewhere, so that their correction survives the next cycle.

Next step

The guide to reconciliation rules and duplicate control goes further on rule design, and the IT operations management library shows how discovered items feed monitoring and event work.