IRE in ServiceNow: Data integrity in CMDB

The ServiceNow Identification and Reconciliation Engine (IRE) is the central mechanism that identifies and reconciles Configuration Items (CIs) in the CMDB, ensuring a single trusted record per asset. It decides when to create, update, or block a CI based on identification rules, reconciliation rules, and source precedence—maintaining the data integrity that ITAM, ITOM, SecOps, and CSDM require to operate with confidence.

What is IRE in ServiceNow?

IRE is the component of ServiceNow This controls how data enters and is updated in the CMDB. Every ingestion that passes through it is evaluated against a set of rules before writing: if the CI already exists, it is updated; if it does not exist, a new record is created; if the source does not have authorization over the attribute, writing is blocked. The goal is straightforward: one CI, one record, one source of truth.

Why data integrity is critical in CMDB

A CMDB lacking data quality compromises the entire operation that depends on it. When the same asset appears duplicated, or when two integrations overwrite each other with each synchronization, reports lose reliability and decisions become based on unstable data. The most frequent symptoms are duplicate CIs, inconsistent attributes, conflicts between sources, and low confidence in dashboards. In environments that feed the CMDB from multiple sources, this risk is structural—and that is precisely the problem that IRE exists to solve.

The three blocks of the IRE

The IRE (Integrated Rule Analysis) is composed of three types of rules that work together. Understanding the function of each is what separates a stable CMDB (Computer-Based Management Database) from a CMDB that "fights with itself".

Block	What decides	Question that answers
Identification rules	How does ServiceNow recognize a CI?	“"Does this CI already exist in CMDB?"”
Reconciliation rules	Which sources can update which attributes?	“"Can this source record this data?"”
Source precedence	Which source prevails in case of conflict?	“"When two sources disagree, who wins?"”

Identification rules

Identification rules use identifier entries with priorities to recognize a CI by unique attributes—serial number, serial number type, name, object ID, among others. IRE evaluates from strongest to weakest entry: for hardware, for example, it first tests the combination of serial number + serial number type; if there is no match, it tests the serial number alone, and so on. As soon as it finds a match, it updates the CI and stops. If no entry matches, it creates a new record. Strong and stable identifiers are the primary defense against duplication.

Reconciliation rules

Reconciliation rules define which data sources can update a table or a set of attributes. They are declared in any class in the hierarchy and inherited by child classes—a rule in the “Server” class applies to both “Linux Server” and “Windows Server,” unless a specific rule dictates otherwise. In practice, this prevents an imported spreadsheet from overwriting an attribute that only Discovery should control.

Data source precedence

When more than one source is authorized to update the same attribute, precedence rules elect the authoritative source by class or attribute. This mechanism eliminates the "ping-pong" effect, where the value of a CI changes with each synchronization because two integrations compete for the same field. Dynamic rules also allow for handling stale CIs: after a defined effective duration, a CI can be updated by a lower-priority source, preventing frozen data.

How does IRE process a CI in practice?

The flow is deterministic, not random. Identification is performed first; reconciliation only occurs after the CI (Conflict Identification Number) has been identified; and conflicts follow a strict order of precedence. In operational terms:

1. A source sends a payload (containing the CI class and its attributes) to the IRE.
2. IRE applies priority-based identification rules until it finds—or does not find—a matching CI.
3. Once the CI (Contractor Indicator) is identified, the reconciliation rules check if the source can record each attribute.
4. In cases of competition between authorized sources, precedence determines which value prevails.
5. The CI is created, updated, or has its attributes masked, according to the rules.

Which ingestion methods use the IRE — and which do not?

This is the most underestimated aspect of CMDB projects: not every method of populating the CMDB goes through IRE. Methods that ignore IRE insert data without identification or reconciliation, and are the most common source of mass duplication.

Method of ingestion	Do you use IRE?
ServiceNow Discovery	Yes
Service Graph Connectors (third-party integrations)	Yes
IntegrationHub ETL (imports)	Yes
Direct REST integrations without Service Graph Connector	No — not recommended
Manual imports outside of IntegrationHub ETL	No — not recommended

IRE, ITAM, ITOM, and CSDM: the chain reaction

The integrity delivered by IRE is not an end in itself—it is the foundation upon which other disciplines operate. ITAM, Reliable CIs mean accurate asset tracking and more assertive licensing and cost decisions. In ITOM, consistent data improves event correlation and root cause analysis, reducing operational noise. And in CSDM, The IRE helps maintain the CMDB structure's adherence to the model, supporting service governance. Without reliable reconciliation, each of these layers inherits the error from the layer below.

Common problems: Duplicate ICs vs. overloaded ICs

Two opposing defects indicate poorly calibrated identification rules. Recognizing them early avoids rework and deduplication in production.

Problem	What happens	Typical cause
Duplicate CIs	Multiple records represent the same asset.	Weak identifiers or identifiers that change over time.
Overloaded ICs	Distinct assets collapse into a single record.	Identification criteria that are too broad.

Best practices for implementing IRE efficiently.

• Start with out-of-the-box (OOTB) rules and understand them before customizing.
• Select the authoritative source by class and attribute, assigning the correct precedence.
• Prioritize strong and stable identifiers (serial numbers are usually better than names).
• Testing rules in a sub-productive environment with real-world scenarios: partial data, conflicting data, and multiple sources.
• Monitor IRE processing logs and handle deduplication queues periodically.
• Align the class and relationship design with the model. CMDBCSDM.
• Audit rules and data quality on a regular basis — data integrity is an ongoing process, not a one-time project.

Specialized execution makes all the difference.

Poorly defined identification and reconciliation rules don't cause immediate errors—they silently degrade the CMDB until reports and automations become unreliable. As a ServiceNow Elite Partner in Brazil and winner of the 2024–2025 Technology Excellence Partner Award, 4MATT works with over 80 certified specialists in the design, calibration, and support of IRE, transforming the CMDB into a stable source of truth for ITAM, ITOM, SecOps, and CSDM.