⬡ Part 5 · Topic 3

Discovery & IRE Deep Dive

The Identification and Reconciliation Engine (IRE) is the gatekeeper for all CI data entering the CMDB. It prevents duplicates, manages conflicts between data sources, and determines the authoritative value for every field. Understanding IRE is the single most important skill for CIS-DF.

📋 7 sections ⏱ ~35 min read 🎯 ~18% exam weight 🏷 IRE · Discovery · Reconciliation

🔗

Builds On — Parts 3 and 4 This topic brings Discovery and IRE together from a CMDB perspective. You need two prior topics for this to make sense: Part 3 (Discovery) — specifically how Vertical Discovery sends a CI payload after classification; and Part 4 T1-T3 (IRE Architecture, Identification Rules, Reconciliation Rules) — the three IRE phases and how rules are configured. This topic focuses on how those systems interact with the CMDB, what logs to check, and the exam-tested edge cases for combined Discovery+IRE scenarios.

Section 1

Why IRE Exists High Priority

Without a gatekeeper, every import and every Discovery run would simply overwrite CI data. Imagine: Discovery finds a server and sets its hostname to "WEB-01". An hour later, a CSV import from the asset management system arrives with hostname "web-server-01" for the same physical machine. Without IRE, whichever ran last wins — creating either duplicates or incorrect overwrites.

The Identification and Reconciliation Engine (IRE) solves this in three phases:

Identification — Is this CI already in the CMDB? Find the existing record, or create a new one if it's genuinely new. Never create a duplicate.
Reconciliation — Multiple sources are reporting values for this CI. Which source should win for each field? Apply the authoritative source rules.
Deduplication — After identification and reconciliation, detect near-duplicate CIs (records that represent the same real-world device) and merge them. See Part 4 Topic 4 for the full deduplication workflow.

🧩

Analogy — Passport Control + Customs IRE is like an airport's arrival process. Identification is Passport Control: "Is this person already in our system? Match them to their existing profile." Reconciliation is Customs: "Multiple agencies (TSA, border patrol, airline) all have data about this traveler. Whose data do we trust for each field? We use the passport for nationality, the airline for seat assignment." IRE applies the same logic to CI data from Discovery, Import Sets, and SGCs.

Section 2

Identification Rules & Identification Entries High Priority

Identification Rules define how IRE determines if an incoming CI payload matches an existing CI in the CMDB. There is one Identification Rule per CI class (or inherited from a parent class).

Each Identification Rule contains one or more Identification Entries. Each Entry specifies a set of fields that, when matched, uniquely identify a CI. Think of Identification Entries as the "fingerprints" — multiple fingerprints can identify the same person.

How Identification Works Step-by-Step

↓

Input

CI Payload Arrives at IRE

An incoming CI payload arrives with a CI class and a set of field values. IRE immediately looks up the Identification Rule configured for that CI class.

Entry Evaluation

Apply Identification Entries in Priority Order

IRE evaluates each Identification Entry in ascending priority order (lower number = higher priority). For each Entry, it checks whether all specified fields match an existing CI in the CMDB. All fields in an Entry must match (AND logic).

Decision

How Many CIs Match?

The outcome of each Identifier Entry falls into one of three paths:

Exactly One Match

Existing CI Updated

IRE identifies the matched CI as the update target. No new record created. Proceeds to Reconciliation.

Multiple Matches

Duplicate Candidate Flagged

More than one CI matches the Entry. IRE raises a "multiple match" event. Tracked in the CMDB Dedupe dashboard for deduplication review.

No Match

Try Next Entry or Create

This Entry didn't match. If more Entries remain, IRE tries the next one in priority order. If all Entries are exhausted, a new CI is created.

✓

No Match — All Entries Exhausted

New CI Created

No Identification Entry matched any existing CI. IRE creates a new CI record in the appropriate class table and proceeds to set its field values via Reconciliation.

Identification Entry Configuration

Each Identification Entry has:

Priority — Integer (1 = highest priority). IRE tries entries in order; the first match wins.
Attributes — one or more field names from the CI class that must ALL match (AND logic). Example: "serial_number" alone, or "name + ip_address".
Qualifier — optional filter to restrict which CIs this entry applies to (e.g., only apply if OS = Linux).
Related Entries — match via related CI values (e.g., match the server by its network adapter's MAC address).

⚠

Exam Trap — All Fields in an Entry Must Match (AND Logic) If an Identification Entry lists "name" and "ip_address," BOTH fields must match an existing CI for that entry to succeed. It's not enough for just name to match — both must. Entries within a rule use OR logic (any entry can succeed), but attributes within an entry use AND logic (all must match).

📘

Core Concept — Inherited Identification Rules Identification Rules can be inherited from parent CI classes. If cmdb_ci_computer has an Identification Rule, cmdb_ci_server inherits it unless a more specific rule is defined for servers. This means you don't need to create separate rules for every subclass — define at the right level of the hierarchy.

Section 3

Reconciliation Rules High Priority

Once IRE identifies the target CI, it moves to the second phase: Reconciliation. Multiple data sources may all report different values for the same CI field. Reconciliation Rules determine which source wins for each field.

Each Reconciliation Rule specifies:

CI Class — which CI type this rule applies to
Field — which specific field is being governed (e.g., ip_address)
Data source precedence — ordered list of data sources; higher position = higher authority
Action — what to do: Accept (use the value), Reject (ignore this source's value), or Merge

Reconciliation Precedence Example

For the os_version field on servers, you might configure:

Discovery (highest authority — it read the OS directly from the server)
ServiceNow CMDB Agent
Third-party ITSM import (lowest authority — manual data entry is less reliable)

If Discovery reports "Windows Server 2022" and the ITSM import reports "Windows 2019," Discovery wins. The ITSM value is stored but not applied to the active field value.

What Happens When No Rule Matches

If no Reconciliation Rule covers a specific field/source combination:

By default, the incoming value overwrites the existing value (last-write-wins)
This is the dangerous default — it means any source can overwrite any field if no rule protects it
Best practice: create Reconciliation Rules for all fields that could be updated by multiple sources

⚠

Exam Trap — No Rule = Last Writer Wins If no Reconciliation Rule exists for a field, the most recent import or Discovery run overwrites the previous value regardless of source quality. This is a common cause of "my CMDB data keeps reverting" issues — a low-quality import is overwriting high-quality Discovery data because no Reconciliation Rule protects the field.

Section 4

Discovery Architecture

ServiceNow Discovery is the automated process of scanning your network to find and inventory CIs. It runs on a schedule or on demand, communicates with devices and applications, and sends the discovered data through IRE into the CMDB.

Key Discovery Components

MID Server

Management, Instrumentation, and Discovery server. A Java agent installed in your network that executes Discovery probes and sends results back to ServiceNow.

IP Range / Discovery Schedule

Defines what to scan (IP ranges or CIDR blocks) and when. The Discovery Schedule triggers the scan and tracks its status.

Probes

Scripts that collect data from devices (SSH, WMI, SNMP). Each probe collects a specific type of data (OS info, running processes, installed software).

Sensors

Process probe results and create CI payloads. Sensors transform raw probe output into structured CMDB data that IRE can consume.

Patterns

Declarative discovery definitions (JSON/YAML) that describe how to discover a specific technology. Patterns replace custom probes/sensors for certified technologies.

Discovery → CMDB Flow

Horizontal Discovery

Scan — Find Live Devices

MID Server pings IP ranges and runs port scans to identify which hosts are alive. Each responding IP is classified by device type (server, router, printer) using port response patterns and SNMP OID lookups.

Vertical Discovery

Probe — Collect Device Attributes

For each live device, MID Server matches credentials and runs targeted probes (SSH/WMI for servers, SNMP for network gear, JDBC for databases) to collect detailed CI attribute data. Raw output is returned to the ServiceNow instance.

Sensor Processing

Sensor Parses Raw Output → CI Payload

Sensors (JavaScript running on the ServiceNow instance) transform raw probe output into structured CI payloads — assigning CI class, identification attributes, and field values ready for IRE.

IRE → CMDB

IRE Identifies, Reconciles → CI Created/Updated

IRE receives the payload, runs Identification (match or create CI) then Reconciliation (apply authoritative field values by source priority). The CMDB CI record is created or updated with only authoritative values.

Section 5

Service Graph Connectors and IRE

Service Graph Connectors (SGCs) are the recommended integration pattern for getting third-party data into the CMDB. Unlike raw Import Sets that write directly to tables, SGCs explicitly route data through IRE.

Feature	Service Graph Connector	Import Set (direct write)
IRE Identification	✓ Always passes through IRE	✗ Bypasses IRE by default
Duplicate prevention	✓ IRE deduplicates	✗ Can create duplicates
Reconciliation rules honored	✓ Yes	✗ No — writes directly
Source tagging	✓ Tagged for reconciliation	Limited
Setup complexity	Higher (requires SGC install)	Lower
Recommended for CMDB	✓ Yes	Only if SGC not available

SGC payloads include the source system identifier and the CI class with identification attributes. IRE uses these to match the incoming payload against existing CIs and apply the configured Reconciliation Rules for that source.

🚨

Warning — Direct Import Set Writes Bypass IRE If a Transform Map writes directly to cmdb_ci_server (target table is the CI table), IRE is not involved. This means no duplicate checking, no reconciliation rules, and no source tagging. This is the main reason direct Import Set writes to CMDB tables are discouraged — they undermine CMDB data integrity. To route Import Sets through IRE, use the CMDB Identification Utility (IRE API) in transform scripts.

Section 6

Duplicate CIs and CMDB Deduplication

Despite IRE's best efforts, duplicates can still enter the CMDB — especially through legacy Import Sets that bypass IRE, or when Identification Rules are misconfigured. ServiceNow provides tools to detect and resolve duplicates.

CMDB Dedupe Dashboard

Shows CI records flagged as potential duplicates by IRE (multiple match condition)
Allows viewing duplicate pairs side by side to compare field values
Provides actions: Merge (combine into one), Delete (remove the less accurate one), or Mark as Not Duplicate

Merge Behavior

When merging two duplicate CIs, ServiceNow must decide which field values to keep. The merge process:

Designates one as the "winner" (master) and one as the "loser" (duplicate)
Applies Reconciliation Rule logic to determine which value survives for each field
Updates all references (incidents, changes, relationships) that pointed to the loser to point to the winner
Marks the loser record as decommissioned or deletes it

⚠

Exam Trap — Merging Does Not Delete Referenced Records When two CIs are merged, relationships (cmdb_rel_ci rows) pointing to the loser CI are re-pointed to the winner CI — they are NOT deleted. Incidents or changes linked to the loser are also re-linked to the winner. The merge is a pointer update, not a data deletion.

Section 7

IRE Tables Reference

IRE configuration lives in a small set of tables. Knowing these table names is tested:

Table	Purpose
cmdb_identifier	Identification Rule — one per CI class; links to Identification Entries
cmdb_identifier_entry	Identification Entry — the specific field combinations used for matching
cmdb_reconciliation_rule	Reconciliation Rule — field-level authoritative source configuration
cmdb_datasource_filter	Data Source Filter — restrict which CIs a source can create/update
cmdb_ire_event	IRE event log — tracks each payload processed, result, and any errors

Exam Quick Reference

Common Exam Traps — Discovery & IRE

IRE has three phases: Identification (find/create CI), Reconciliation (apply authoritative field values), then Deduplication (detect and merge duplicate CIs) — see Part 4 for full detail
Identification Rule = one per CI class; contains one or more Identification Entries
Identification Entry attributes = AND logic (all must match); multiple Entries = OR logic
Priority on Entries: lower number = tried first
No Reconciliation Rule = last writer wins (dangerous default)
SGCs route through IRE; direct Import Set writes to CMDB tables bypass IRE
Discovery updates CIs through IRE — never updates Asset records
MID Server = Java agent in your network; runs probes, sends results to ServiceNow
Probes collect raw data; Sensors transform probe output into CI payloads
Merge re-points all references from loser to winner — does NOT delete referenced records
IRE tables: cmdb_identifier, cmdb_identifier_entry, cmdb_reconciliation_rule

Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

Discovery & IRE Deep Dive Quiz 1 / 4

An Identification Entry lists "name" and "ip_address" as its attributes. A payload arrives with name="WEB-01" but no ip_address field. What does IRE do with this entry?

💡 Explanation

B is correct. Identification Entry attributes use AND logic — ALL fields in the entry must be present in the payload for the entry to even attempt a match. If ip_address is missing, the entire entry is skipped. IRE then tries the next entry (lower priority, higher number) in sequence. This is a common cause of duplicate CI creation: Discovery doesn't collect a key identifier field, so IRE skips the matching entry and creates a new record every run.

CMDB Health & Governance →