Identification & Reconciliation Engine: Why IRE Matters

Picture this. Your organisation runs ServiceNow Discovery, SCCM, and a third-party asset tool, all of them scanning the same infrastructure. Every time they report on the same server, the CMDB gets a new record. Three discovery sources, one physical machine, five duplicate CIs. Reports are wrong, incident routing is wrong, and nobody can figure out why the numbers keep changing.

That's not an unusual scenario. It's one of the most common CMDB problems teams deal with. And it's exactly the kind of problem the ServiceNow Identification & Reconciliation Engine was built to prevent. If you've heard of IRE but aren't quite sure what it does or why it matters, this article walks through it properly.

What Is the Identification & Reconciliation Engine in ServiceNow?

IRE, short for Identification and Reconciliation Engine, is the main ServiceNow product which is placed between your discovery and integration products and CMDB. In fact, any piece of information coming from a source (Discovery, Service Mapping, import set, third-party integration) is not inserted directly into CMDB but passes through IRE first.

IRE's job is to answer two questions before anything gets written to the database. First: does this CI already exist? If a server is already in the CMDB, the incoming data should update that record, not create a second one. Second: should this attribute value be updated? Just because a source is reporting a value doesn't mean it should overwrite what's already there, especially if that value came from a more authoritative source.

And this pair of questions, whether it exists, and whether it needs to be updated, correlates with two parts of the IRE product – identification and reconciliation. You will understand their functions and get the whole picture. And to understand where IRE is situated in general architecture of your ServiceNow CMDB, you should find out its connection to other products.

How Does the ServiceNow Reconciliation Engine Work?

When data arrives, IRE runs through a defined process before anything touches the CMDB.

The first thing it checks is whether the incoming data includes a source_name and source_native_key, essentially the source's own unique identifier for that CI. If those are present, IRE can match the incoming record to an existing CI quickly and reliably without needing to run through rule-based matching. It's the fastest path through the engine and the most reliable, which is why well-configured discovery sources should always be passing those values through.

If those identifiers aren't present, IRE falls back to identification rules. These are class-specific rules that define which attributes to use for matching: serial number for a server, MAC address for a network device, and so on. The engine works through the rules in priority order until it gets a match (or determines the CI doesn't exist yet).

Once a CI is identified, the ServiceNow reconciliation engine takes over. This is where attribute-level decisions happen. Each source is assigned a priority, and for each attribute, the value from the highest-priority source is what gets written. So if ServiceNow Discovery has a priority of 1 and SCCM has a priority of 2, Discovery's values win on any attribute where both sources are reporting. If a source tries to update an attribute it doesn't have authority over, that update is blocked, the existing value is protected.

What Are the Main Components of IRE?

IRE is made up of several working parts that together handle the full journey from incoming data to committed CMDB record:

• Identification rules - define the matching criteria per CI class. What makes a server unique? A serial number. What makes a network device unique? A MAC address. These rules are what stop two records for the same physical asset from living separately in the CMDB.
• Reconciliation rules - control which sources can update which attributes, and in what priority order. Without these, any discovery tool can overwrite any value, which is how trusted data gets corrupted by a less reliable source.
• IRE data source rules - go a step further and control which sources are even allowed to create new CIs in a given class. This prevents rogue imports from flooding the CMDB with records they have no business creating.
• Partial payload tables - hold incomplete CI records that don't yet have enough data to be identified properly. The engine waits for a fuller picture rather than creating a guessed record. Partials older than 90 days are cleaned up automatically.
• IRE APIs - including CreateOrUpdateCIEnhanced() and identifyCIEnhanced, which allow integrations and custom workflows to send data through IRE rather than writing directly to CMDB tables. Any integration that bypasses these APIs and writes directly to the CMDB tables is also bypassing all of IRE's protections.

Why Does IRE Matter for CMDB Accuracy and IT Operations?

The honest answer is that without IRE working properly, the CMDB deteriorates over time. Discovery tools find new machines and create records. Other tools find the same machines and create more records. Import sets bring in data that partially overlaps with what's already there. And gradually the CMDB fills up with duplicates, stale data, and conflicting attribute values that nobody can fully trust.

The practical impact of that goes well beyond a data quality problem. Incident management breaks down when tickets route to the wrong team because the CI record is wrong. Change management breaks down when you can't accurately see what a CI's relationships and dependencies are. Licence compliance breaks down when the asset count is unreliable. CMDB Health scoring, which many organisations now report on, drops, and the downstream tools that depend on CMDB accuracy start producing unreliable results.

With three or more discovery sources scanning the same environment, a single server can generate five or more duplicate CI records. Across 5,000 devices at a 10% duplication rate, that's around 500 phantom CIs distorting every report, SLA metric and compliance calculation that touches them. (Source: Virima, 2025)

IRE is the mechanism that keeps that from happening, not just on day one, but continuously, as new data comes in every day from every source.

What Happens When IRE Finds Duplicate or Conflicting CI Records?

IRE's default behaviour when it finds more than one existing CI matching an incoming record is to do nothing. It doesn't guess which record to update. It doesn't merge them automatically. It logs an IRE error, flags the situation as ambiguous, and waits for a human to sort it out. That's the right call; a silent wrong merge would be worse than a held record.

When duplicates are found, the fix process typically goes like this:

1. Duplicate Detection on the CMDB Health dashboard should be run in order to create de-duplication tasks.
2. The golden record for each set should be determined. The golden record is the most complete record from the most reliable discovery source.
3. It should be merged with all useful information, and other records have to be retired with the notation of a source creating a record.
4. There is a need to trace and correct an integration or import process that has caused duplicates. Otherwise, there will be duplicates once again.
5. Identification criteria have to be tightened to make sure that the same match failure will not happen again.

When there is a situation when two sources provide different values for one attribute, reconciliation rules are used to solve the issue. The priority value of a source is used. The situation can become non-deterministic if the priority value of two sources is the same.

How Can Businesses Configure and Troubleshoot ServiceNow IRE?

Configuration happens in a few different places in ServiceNow. Identification rules are set per CI class in the CI Class Manager, where you define which attributes are used for matching and in what order. Reconciliation rules are also configured per class, with source priority set at the attribute level. IRE data source rules sit alongside these and define which sources can create new records in each class.

A few configuration principles that matter in practice:

• Use stable identifiers. Serial number for servers, MAC address for network devices. IP addresses change; using them as your primary identifier will cause identification failures when IPs are reassigned.
• Never assign equal priority to two sources for the same attribute. When priorities match, reconciliation becomes unpredictable.
• Don't bypass IRE. Any data written directly to CMDB tables via CSV loads, custom API calls or direct inserts skips the engine entirely. Those records won't have gone through identification or reconciliation, and they won't play by the rules you've set up.
• Review rules quarterly. Infrastructure changes, new discovery tools, decommissioned sources, and new CI classes should trigger a review of identification and reconciliation rules to make sure they still reflect reality.

For troubleshooting, the cmdb_ire_log table is the main place to start. IRE logs every identification failure, ambiguous match and reconciliation decision, so when something isn't going into the CMDB the way you expected, the log will usually tell you exactly why. The CMDB Health dashboard tracks duplicate rates and health scores over time, which gives you a leading indicator before problems get serious.

How Does IRE Improve ServiceNow ITOM and IT Asset Management?

IRE is the foundation that makes both ServiceNow ITOM solutions and ServiceNow IT Asset Management reliable. Discovery in ITOM depends on IRE to match discovered assets to existing CMDB records rather than creating duplicate records every scan cycle. Service Mapping uses IRE to build accurate application service maps, if the underlying CI data is duplicated or conflicting, the service map is wrong, and incident response suffers for it.

On the ITAM side, software licence compliance depends entirely on knowing how many instances of something actually exist. Duplicate CIs inflate that count. Stale records keep licences allocated to decommissioned assets. IRE's identification and reconciliation process is what keeps the asset inventory accurate enough to base licence decisions on.

For organisations that run both ITOM and ITSM on ServiceNow, IRE is the shared data layer that keeps both sides consistent. When a change request references a CI, that CI needs to reflect the actual current state of the infrastructure, which is only possible if the data coming in from discovery and integrations has been properly identified and reconciled before it hits the CMDB. That relationship between ServiceNow ITOM and ITSM is what makes a well-configured IRE so operationally important.

FAQs

What is the Identification and Reconciliation Engine in ServiceNow?

The Identification and Reconciliation Engine (IRE) is a core ServiceNow component that processes all incoming CI data before it reaches the CMDB. It first identifies whether a CI already exists in the database, then applies reconciliation rules to determine which source's attribute values should be written, preventing duplicates and protecting trusted data from being overwritten by lower-priority sources.

What is the difference between identification and reconciliation?

Identification answers the question: does this CI already exist in the CMDB? It matches incoming records to existing CIs using identifiers like serial number or MAC address, or creates a new CI if no match is found. Reconciliation runs after identification and answers a different question: which source's value for each attribute should be written to the CMDB? It uses source priority rules to decide, so only authoritative sources can update each field.

Is the ServiceNow reconciliation engine available for download?

There is no Identification & Reconciliation Engine download; it's a built-in part of the ServiceNow platform, not a separate plugin or store application. IRE is active on every ServiceNow instance as a core CMDB capability. What you can configure are the identification rules, reconciliation rules and data source rules that control how the engine behaves for your specific environment and CI classes.

How does IRE prevent duplicate CIs?

When data arrives from a discovery source or integration, IRE checks it against identification rules for that CI class before writing anything. If a matching CI already exists, the incoming data updates that record rather than creating a new one. If more than one existing CI matches, which signals a problem in the CMDB or the rules, IRE logs the ambiguous match and holds the update rather than guessing, leaving an admin to investigate and resolve it.