Identification Rules — How IRE Knows If a CI Already Exists
The previous topic introduced IRE's three phases. Now we go deep on Phase 1: Identification.
Every time data arrives at IRE, the very first question is "have we seen this CI before?"
Identification Rules are how IRE answers that question — and getting these rules right
is one of the most impactful configuration decisions in your CMDB.
Before IRE can decide whether to create a new CI or update an existing one, it must answer
a deceptively simple question: "Is the thing described in this incoming payload the
same thing as a CI that already exists in the CMDB?"
This sounds easy. In practice, it's one of the hardest problems in CMDB management:
Different sources use different identifiers. AWS uses instance IDs
(i-0123abc). Discovery finds the same machine and knows its hostname
(web-prod-01) and serial number (SN-12345). These look completely different —
but they refer to the same physical server.
Not all identifiers are stable. IP addresses change when a server moves
to a different subnet. Hostnames change when a machine is renamed. If you identify
servers by IP or hostname alone, Discovery will create duplicate CIs after any rename
or IP change.
Some identifiers are not unique. MAC addresses look unique but
can be cloned. Hostnames should be unique but aren't always enforced.
Serial numbers are often the most reliable — but not all devices have them.
🔍
Analogy — Identity Like a Government ID Check
Imagine checking into a hotel under different circumstances. Sometimes you show your
passport (serial number — always unique). Sometimes you show a driver's license
(hostname — usually unique, but you could have a same-name twin). Sometimes you just
say your name (IP — definitely not unique). The front desk needs to know which form
of ID is trustworthy enough to match you to your reservation. Identification Rules
tell IRE which fields are trustworthy enough to identify a CI.
Section 2
Anatomy of an Identification Rule
An Identification Rule is a configuration record in
ServiceNow that defines: for CI class X, use field(s) Y to determine uniqueness.
Key components of an Identification Rule:
Component
What It Does
Example
CI Class
Which CMDB table this rule applies to
cmdb_ci_linux_server
Identifier Entries
The ordered list of attribute combinations to try
Try serial+make+model first, then IP+OS
Identifier Priority
Order of identifiers — higher priority tried first
Serial number (priority 1) before hostname (priority 2)
Lookup Rules
Related CI lookups — find this CI by finding a related CI first
Find the network adapter, then the server it belongs to
Apply to
Whether rule applies to child classes too
If checked, cmdb_ci_server rule also applies to all server subclasses
Where to Find Identification Rules
Navigate to Configuration → CMDB Identification and Reconciliation →
Identification Rules. ServiceNow ships with pre-configured rules for
all major CI classes. You can modify existing rules or create new ones for
custom CI classes.
💡
Key Concept — Identification Rules Are Per Class, Not Global
A rule for cmdb_ci_linux_server only applies when IRE receives
a payload tagged as that class. Rules do not apply across classes —
a Linux server identification rule cannot find a Windows server, even if both
have the same serial number. IRE always uses the CI class from the payload
to select which rules to evaluate.
Section 3
Identifiers and Identifier Entries — The Matching Logic
Within an Identification Rule, the actual matching is done by
Identifier Entries. Each Identifier Entry specifies
a set of CMDB fields that, when all matched, uniquely identify a CI.
How Multiple Identifier Entries Work
A single Identification Rule can have multiple Identifier Entries with different priorities.
IRE evaluates them in priority order — it tries the highest-priority entry first.
If that entry matches a CI, identification is complete. If not, it tries the next entry.
If no entries match, the CI is treated as new.
↓
Input
Incoming CI Payload
Payload arrives: cmdb_ci_linux_server with serial_number=SN-XYZ, ip_address=10.0.1.5, host_name=web-01. IRE selects the Identification Rule for this CI class.
1
Entry 1 — Priority 1
Match on serial_number + manufacturer
IRE tries the highest-priority Identifier Entry first. It queries the CMDB for a Linux server CI where serial_number = SN-XYZ.
Match Found
Stop — CI Identified
Existing CI found. IRE uses its sys_id as the update target. Entry 2 is never evaluated.
No Match
Try Entry 2
Serial number not found. IRE falls through to the next Identifier Entry in priority order.
2
Entry 2 — Priority 2 (fallback)
Match on ip_address + host_name
Only evaluated if Entry 1 failed. IRE queries for a Linux server CI where ip_address = 10.0.1.5 AND host_name = web-01. Both fields must match (AND logic).
Match Found
Stop — CI Identified
Existing CI found via IP + hostname. IRE uses its sys_id as the update target.
No Match
All Entries Exhausted
No entry matched. Proceeds to create a new CI.
✓
No Match — Create Path
New CI Created
No Identifier Entry matched any existing CI. IRE creates a new cmdb_ci_linux_server record and proceeds to Reconciliation to set its field values.
Multi-Field Identifiers (AND Logic)
When an Identifier Entry specifies multiple fields, all fields must match
for that entry to succeed. This is AND logic. For example:
Entry with fields: serial_number AND manufacturer AND model_id
For this entry to match: all three fields in the payload must match corresponding values in an existing CI
Why require both serial AND manufacturer? Serial numbers from different manufacturers can occasionally collide. The combination is much more reliable.
⚠
Exam Pattern — Missing Fields = Entry Skipped
If an Identifier Entry requires fields A, B, and C, but the incoming payload
only provides A and B (field C is missing or null), IRE skips that Identifier Entry
entirely and tries the next one. It does not do a partial match. This is why
Discovery patterns must be configured to collect all fields that Identification
Rules expect — missing fields mean lower-quality identification and potentially
more duplicate CIs.
Section 4
Out-of-Box Identification Rules — What ServiceNow Ships With
ServiceNow ships with identification rules for all major CMDB CI classes.
Understanding the defaults helps you know what Discovery must collect.
CI Class
Primary Identifier (Entry 1)
Fallback Identifier (Entry 2)
cmdb_ci_server / cmdb_ci_computer
serial_number + manufacturer + model_id
ip_address + host_name (less reliable)
cmdb_ci_linux_server
serial_number + manufacturer + model_id
ip_address + host_name
cmdb_ci_win_server
serial_number + manufacturer
ip_address + host_name
cmdb_ci_network_adapter
mac_address
(no fallback — MAC must be present)
cmdb_ci_ip_address
ip_address + nic_address (MAC)
ip_address alone (less reliable)
cmdb_ci_database_instance
name + type + host (server CI relationship)
(lookup rule — find server first)
cmdb_ci_appl (software)
name + version + type + host
name + host (no version check)
Why Serial Number Is the Gold Standard
For physical and virtual servers, serial number (combined with manufacturer) is the
most reliable identifier because:
It doesn't change when a server is renamed, re-IP'd, or moved to a different subnet
It's assigned by the hardware manufacturer and globally unique (in practice)
Both Discovery and most SGCs can reliably collect it
IP address as a sole identifier is problematic:
a DHCP environment reassigns IPs constantly, and after a server is decommissioned,
another server may inherit its IP — causing two different servers to map to the same CI.
💡
Tip — Check What Your Discovery Patterns Actually Collect
The out-of-box Identification Rule for servers requires serial_number + manufacturer + model_id.
If your Discovery patterns don't collect the serial_number (maybe SNMP doesn't expose it),
IRE will fall through to the IP+hostname fallback. Audit your patterns and rules together —
they must be aligned.
Section 5
Lookup Rules — Finding CIs Through Relationships
Some CI classes are naturally identified through their relationship to another CI.
For example, a database instance doesn't have a serial number. Instead, it's unique
based on which server it runs on and what its name is.
Lookup Rules handle this. A Lookup Rule tells IRE:
"To identify a CI of class X, first look up the related CI of class Y using these
fields, and then find CI X that is related to the CI Y you found."
Database Instance Lookup Rule — Step by Step
↓
Input
Incoming DB Instance Payload
Payload arrives for a database instance CI: name=PROD_DB, type=Oracle, host=web-server-01. The DB instance cannot be uniquely identified by its own attributes alone — its identity is tied to the server it runs on.
1
Lookup Step
Find the Referenced Host Server CI
The Lookup Rule instructs IRE: "First find the server CI where host_name = web-server-01." IRE queries cmdb_ci_server and retrieves that record's sys_id.
Server Found
sys_id Retrieved
Host server exists in CMDB. Proceed to Step 2 with the server's sys_id.
Server Not Found
Lookup Fails — Retry Later
Host CI doesn't exist yet. Payload is queued for retry. This is why infrastructure CIs must be discovered before application CIs.
2
Compound Match
DB Instance Found via Relationship
IRE queries: "Find the DB instance CI where name=PROD_DB AND type=Oracle AND runs_on=[server sys_id]." The compound key (own attributes + host relationship) uniquely identifies the DB instance → UPDATE.
When Lookup Rules Fail
If the Lookup Rule cannot find the referenced CI (e.g., the host server doesn't
exist in the CMDB yet), the identification fails and the payload is typically
queued for retry. This is why Discovery processes infrastructure CIs
(servers, network devices) before application CIs (databases, software) —
the dependent CIs must exist first.
⚠
Exam Pattern — Lookup Rule Dependency Order
When a question asks why application CIs (databases, software) are not appearing
in the CMDB after Discovery, a common answer is that the host server CIs were
not created first. Lookup Rules require the referenced CI to already exist.
Discovery processes CIs in dependency order to minimize this problem.
Section 6
Independent vs. Dependent Identifiers
ServiceNow classifies CI identifiers into two types based on whether they
can stand alone or require a relationship.
Independent Identifiers
The CI is identified using only its own attributes — no relationship to another CI
is needed. Servers (using serial numbers) are the classic example. These are
the simplest and most reliable identifiers.
Example: Server identified by serial_number + manufacturer
Reliability: High — no dependency on other CIs existing first
Best used for: Infrastructure CIs (servers, switches, routers)
Dependent Identifiers
The CI is identified using a combination of its own attributes and its
relationship to another CI. These use Lookup Rules internally.
Example: Database instance identified by name + type + host CI
Reliability: Lower — depends on the referenced CI being correctly identified first
Best used for: Application and service CIs that don't have their own hardware identifiers
💡
Key Concept — CI Discovery Order Matters
Because dependent identifiers rely on the host CI existing first, the order
of Discovery and IRE processing matters. ServiceNow Discovery is designed to
process network infrastructure first (IP addresses, network adapters), then servers,
then running services and software. This ensures that by the time a database
instance payload arrives at IRE, its host server CI already exists.
Section 7
Troubleshooting Identification — Common Failures
Most CMDB quality problems (duplicate CIs, CIs not appearing, wrong CI types)
trace back to Identification Rule issues. Here's how to diagnose them.
Symptom: Duplicate CIs After Discovery Runs
Root cause: IRE is not matching the incoming CI to the existing CI. Instead of
updating the existing one, it's creating a new one each time Discovery runs.
Diagnostic steps:
Check the IRE Log (cmdb_ire_event): look for action="insert" when you expect action="update"
Check what Identifier Entry IRE used to try to match (the "Matched on" field)
Compare: what fields did the Discovery pattern send? What fields does the Identifier Entry require?
Common finding: Discovery sends hostname but Identifier Entry requires serial_number. Serial is missing → IRE treats it as a new CI.
Symptom: No identification rule found for class X
Root cause: IRE received a CI payload for class X but has no Identification Rule
for that class. This happens when:
Discovery Pattern creates CIs of a custom class that doesn't have a rule yet
An SGC targets a class that was recently added to the CMDB hierarchy
Fix: Create an Identification Rule for class X with appropriate Identifier Entries.
Symptom: Multiple CIs match — dedup event created
Root cause: IRE found more than one existing CI that matches the incoming payload's
identifiers. This means duplicates already exist in the CMDB.
IRE creates a deduplication event (covered in Topic 4). The incoming update
is typically held until the duplicate is resolved.
Symptom: Wrong CI class in CMDB
Root cause: The Discovery Pattern or SGC sends the wrong CI class in the payload.
IRE uses the class from the payload — it doesn't infer the correct class.
Example: Pattern sends cmdb_ci_computer for a
Linux server. IRE creates a generic computer CI instead of a Linux server CI.
Linux-specific fields are not populated.
⚠
Warning — Modifying Identification Rules Affects Existing CIs
Changing an Identification Rule mid-production can cause previously-matched CIs
to no longer match — creating new duplicate CIs for the same physical devices.
Test Identification Rule changes in a sub-production environment first. Use the
"Test Identification" utility in ServiceNow to simulate how a payload would be
processed without actually writing to the CMDB.
Section 8
Custom Identification Rules for SGC-Specific CI Classes
Service Graph Connectors often introduce new CI classes not present in standard
Discovery. For example, an AWS SGC might create:
Out-of-box, ServiceNow ships Identification Rules for classes defined in its baseline
content. When you activate an SGC plugin, the plugin also deploys Identification Rules
for its new CI classes. However, if you build a custom SGC or custom CI class,
you must create the Identification Rules manually.
Choosing Identifier Fields for SGC-Specific Classes
Cloud resources typically have cloud-native identifiers that are globally unique:
AWS resources: ARN (Amazon Resource Name) — globally unique, stable, changes only if resource is deleted/recreated
Azure resources: Resource ID — full path including subscription, resource group, and name
GCP resources: Project + resource name combination
Kubernetes: namespace + name (pods are ephemeral — consider using Deployment instead)
⚠
Exam Pattern — SGC Activating Plugins Also Deploys IRE Rules
When you install a ServiceNow Service Graph Connector (via Plugin Manager or Store),
the plugin deployment automatically creates the Identification Rules and Reconciliation
Rules for all new CI classes the SGC introduces. You do NOT need to create these manually
for ServiceNow-published SGCs. This is different from custom SGCs where you must
create the rules yourself.
Exam Quick Reference
Identification Rules — Key Facts
Identification Rule = configuration record that tells IRE how to find existing CIs of a given class.
Per CI class. Rules for cmdb_ci_linux_server don't apply to cmdb_ci_win_server.
Identifier Entries are evaluated in priority order. All fields in an entry must match (AND logic). If any field is missing from payload, that entry is skipped.
Serial + manufacturer + model = gold standard for physical/virtual servers. Stable across renames and IP changes.
IP address as sole identifier = risky. DHCP environments reassign IPs. Never use alone.
Lookup Rules = identify a CI by first finding a related CI. Used for application-layer CIs (databases, software).
Missing Identification Rule = no CI created. IRE drops payloads with no matching rule for the class.
SGC plugin deployment creates Identification Rules automatically for SGC-specific classes. Custom classes need manual rules.
IRE Log (cmdb_ire_event) shows what matched (or didn't) and why. First diagnostic step.
Test Identification utility lets you simulate IRE processing without writing to CMDB. Use before changing rules in production.
Term Grid
Identification Rule
IRE configuration record that defines how to uniquely identify CIs of a specific class. Contains Identifier Entries and optional Lookup Rules.
Identifier Entry
A set of fields within an Identification Rule that must ALL match for identification to succeed. Multiple entries in a rule are tried in priority order.
Lookup Rule
Part of an Identification Rule. Tells IRE to first find a related CI, then use that CI's sys_id as part of identifying the incoming CI. Used for dependent CIs like databases.
Independent Identifier
CI identified using only its own attributes. No relationship required. Servers with serial numbers are the classic example.
Dependent Identifier
CI identified using its own attributes plus a relationship to another CI. Requires the related CI to already exist in CMDB.
Test Identification Utility
ServiceNow tool that simulates IRE identification against a sample payload without writing to the CMDB. Used to validate rule changes before production.
Exam Checkpoint
Practice Questions
Click any question to reveal the answer and explanation.
1. Discovery runs nightly and consistently creates duplicate Linux server CIs. The IRE log shows action="insert" for CIs that already exist. The Identification Rule for cmdb_ci_linux_server has Entry 1: serial_number + manufacturer + model_id. What is the most likely root cause?
A) The Identification Rule is configured for the wrong CI class
B) The Discovery patterns are not collecting serial_number, causing IRE to skip Entry 1 and find no match
C) The IRE log is showing false positives and the CIs are not actually duplicates
D) The Discovery schedule is running too frequently
💡 When an Identifier Entry has missing fields, what does IRE do?
Answer: B — If the Discovery pattern doesn't collect serial_number (or it's not available from the device), the payload arrives at IRE without that field. Since Entry 1 requires all three fields (serial + manufacturer + model), IRE skips Entry 1. If there's no fallback entry that matches either, IRE treats the CI as new and creates a duplicate. Fix: ensure the Discovery pattern collects serial_number, or add a fallback Identifier Entry that uses fields the pattern does collect.
2. An administrator wants to add a new custom CI class (cmdb_ci_custom_appliance) to the CMDB and plans to populate it using a custom SGC. What must the administrator configure in IRE before the SGC can successfully create CIs of this class?
A) Nothing — IRE automatically creates identification rules for all new CI classes
B) An Identification Rule with at least one Identifier Entry for cmdb_ci_custom_appliance
C) A Transform Map for the new CI class
D) A new Discovery Schedule targeting the custom appliance
💡 What happens when IRE receives a payload for a class with no Identification Rule?
Answer: B — IRE requires an Identification Rule for every CI class it processes. Without one, the payload fails with "No identification rule found for class cmdb_ci_custom_appliance." ServiceNow-published SGC plugins create rules automatically, but custom classes need manually created rules. Transform Maps (C) are for Import Sets, not SGC/IRE.
3. A Lookup Rule is configured for cmdb_ci_database_instance to find its host server first. Discovery reports a database instance on server "db-host-01", but that server CI doesn't yet exist in the CMDB. What happens to the database instance payload?
A) IRE creates the database instance CI without a host relationship
B) IRE creates both the server CI and the database instance CI simultaneously
C) The Lookup Rule fails — the database instance payload cannot be identified, and the CI is not created (or queued for retry)
D) IRE creates the database instance and flags it for manual relationship assignment
💡 Lookup Rules require the referenced CI to already exist. What if it doesn't?
Answer: C — A Lookup Rule requires the referenced CI (the host server) to exist in CMDB before the dependent CI (database instance) can be identified. If the host doesn't exist, the Lookup Rule cannot find it, identification fails, and the database instance CI cannot be processed. Discovery processes CIs in dependency order (infrastructure before applications) to minimize this — but if a server CI is missing, its dependent application CIs will also be missing.
4. An administrator is configuring a new Identification Rule for Linux servers and must choose between two Identifier Entry options: (A) ip_address + host_name or (B) serial_number + manufacturer + model_id. Which is more reliable and why?
A) Option A — IP address is always unique on a network
B) Option B — Serial number is stable across renames and IP changes; IP and hostname change frequently
C) Both are equally reliable
D) Option A — hostnames are enforced to be unique by DNS
💡 Which identifier is stable across server lifecycle events like renames and IP changes?
Answer: B — Serial number (combined with manufacturer + model) is the gold standard for server identification. Serial numbers are assigned by the hardware manufacturer and don't change throughout the server's life. IP addresses change in DHCP environments or when servers move subnets. Hostnames change during renames. After any such change, an IP/hostname-based rule would fail to match the existing CI and create a duplicate.
5. An administrator installs the ServiceNow AWS Service Graph Connector plugin from the ServiceNow Store. Do they need to manually create Identification Rules for the new AWS-specific CI classes (like cmdb_ci_aws_ec2_instance)?
A) Yes — all Identification Rules must be created manually regardless of how the SGC is installed
B) No — when a ServiceNow-published SGC plugin is installed, it automatically deploys Identification Rules and Reconciliation Rules for all new CI classes it introduces
C) Yes — Identification Rules are customer-specific and cannot be shipped with a plugin
D) No — Identification Rules are not needed for cloud CIs because they use API-generated IDs
💡 What does a ServiceNow-published SGC plugin include beyond just connector code?
Answer: B — ServiceNow-published Service Graph Connector plugins are comprehensive packages. Installing the plugin deploys the connector configuration, CI class extensions, Identification Rules, Reconciliation Rules, and often default Reconciliation Priority. You only need to create Identification Rules manually when building custom integrations or custom CI classes not covered by any existing SGC plugin.
Exam Checkpoint
Practice Questions
4 questions · Select an answer to see the explanation immediately.
Identification Rules Quiz1 / 4
Discovery is creating duplicate Linux server CIs nightly. The IRE log shows action="insert" for CIs that already exist. The Identification Rule uses Entry 1: serial_number + manufacturer + model_id. What is the most likely root cause?
💡 Explanation
B is correct. If the Discovery pattern doesn't collect serial_number, the payload arrives at IRE without that field. Since Entry 1 requires ALL three fields (AND logic), IRE skips the entire entry when any field is missing. With no matching entry, IRE treats the CI as new and inserts a duplicate. The fix: ensure Discovery patterns collect serial_number, or add a fallback Identifier Entry using fields that ARE collected (e.g., hostname + ip_address as a secondary fallback).
An Identification Rule for cmdb_ci_linux_server has two entries: Entry 1 (priority 10): serial_number + manufacturer, Entry 2 (priority 20): ip_address + host_name. A payload arrives with serial_number but no ip_address. Which entry does IRE use?
💡 Explanation
C is correct. IRE evaluates Identification Entries in priority order — lower priority number = higher priority = tried first. Entry 1 (priority 10) is tried first. Since the payload has serial_number and manufacturer, Entry 1 can match an existing CI. If it succeeds, IRE uses that match and stops — Entry 2 is never evaluated. Entry 2 would only be used if Entry 1 has no fields or all required fields are missing from the payload.
Which identifier combination is most reliable for physical server Identification Rules and why?
💡 Explanation
B is correct. Serial number + manufacturer + model_id is the gold standard for physical servers. The serial number is assigned by the hardware manufacturer and does not change throughout the server's life. IP addresses change in DHCP environments or when servers are moved. Hostnames change during renames. MAC addresses can change when NICs are replaced. Only hardware-assigned identifiers survive server lifecycle events without causing duplicate CIs.
A Lookup Rule for cmdb_ci_db_instance requires finding its host server first. Discovery sends a database instance payload but the host server CI doesn't yet exist in the CMDB. What happens?
💡 Explanation
C is correct. A Lookup Rule requires the referenced CI (the host server) to already exist in the CMDB. If the host doesn't exist, the Lookup Rule cannot locate it, identification fails, and the dependent CI (database instance) is not created. Discovery processes CIs in dependency order — infrastructure before applications — to minimize this. If a server CI is missing, its dependent application CIs will also be missing from the CMDB until the server CI is created first.