2.2 Authoring Identification Rules

Authoring Identification Rules

In a multi-source CMDB where data is ingested from various sources (such as discovery tools, import sets, and API integrations), maintaining data integrity is a major challenge. Without strict identification mechanisms, different sources might create duplicate records for the same Configuration Item (CI). ServiceNow solves this problem using the Identification and Reconciliation Engine (IRE), which relies on developer-defined Identification Rules.

---

Introduction to the Identification and Reconciliation Engine (IRE)

The IRE is a centralized platform API that processes all incoming CI data payloads. Before a CI is inserted or updated in the CMDB, the IRE evaluates the payload attributes against existing database records.

An Identification Rule is a container that dictates how the IRE should determine if an incoming CI represents an existing record. Every class in the CMDB can have at least one identification rule. If a class does not have its own rule, it inherits the rule of its parent class.

For example, the Hardware [cmdb_ci_hardware] class has a default identification rule. Because the Server class extends Hardware, it inherits this rule unless an administrator defines a more specific identification rule directly on the Server class.

---

Anatomical Structure of Identification Rules

An identification rule consists of two main components:

1. Identifier Entries: The actual search criteria (attributes) used to look up matching records.
2. Lookup Rules: Rules that instruct the IRE to search related child tables to find matching records.

Identifier Entries & Search Sequence

Identifier entries define the fields that the IRE will query. Each entry is assigned an Order value (e.g., 100, 200, 300). The IRE evaluates these entries sequentially in ascending order:

During execution, the IRE follows a strict logic:

• It runs the query for the entry with the lowest Order value.
• If it finds a single match, the lookup succeeds. The IRE associates the incoming data with that existing CI and stops evaluating further entries.
• If it finds no match, it moves to the next entry in the sequence (higher Order).
• If it finds multiple matches (a duplicate scenario), the IRE halts evaluation and creates a De-duplication Task (or handles it according to class settings), as a multi-match is considered ambiguous and dangerous for automated reconciliation.
• If all entries are evaluated and no match is found, the IRE creates a new CI record.

---

Independent vs. Dependent Classes

CMDB classes are categorized as either Independent or Dependent based on how their identity is established.

Independent Classes

An independent class represents a component that can stand alone and be uniquely identified by its own properties. Examples include:

• Server [cmdb_ci_server]
• Database [cmdb_ci_database]
• Network Switch [cmdb_ci_ip_switch]

An independent CI does not need a parent CI to establish its identity. Its identification rule only queries its own attributes (such as Serial Number or Name).

Dependent Classes

A dependent class represents a component that cannot exist or be uniquely identified without a parent CI. Examples include:

• Network Adapter [cmdb_ci_network_adapter] (dependent on a Server)
• Database Instance [cmdb_ci_db_instance] (dependent on a Database Server)
• Software Installation [cmdb_sam_sw_install] (dependent on a Computer)

For a dependent class, a serial number or name alone is not enough to establish uniqueness. For example, two different servers might both have a network adapter named eth0. To identify eth0 uniquely, the IRE must know which server it belongs to.

Metadata Rules for Dependent Relationships

To enable dependent identification, administrators must define Metadata Rules (also called Relationship Rules) in the CI Class Manager. These rules define:

1. The Parent Class: The class of the supporting CI.
2. The Hosting/Containment Relationship: The relationship type that links the dependent CI to the parent (e.g., "Contains::Contained by" or "Runs on::Hosts").

When the IRE receives a payload for a dependent CI, it first identifies the parent CI. Once the parent CI is resolved, the IRE searches for a dependent CI that is linked to that specific parent via the defined relationship.

---

Advanced Identification Configuration

Lookup Rules

Sometimes, matching attributes are not stored on the CI table itself, but on a related 1-to-many child table. For example, a server may have multiple serial numbers stored in the Serial Number [cmdb_serial_number] table.

To match based on these values, administrators configure Lookup Rules within the identifier entry. A lookup rule instructs the IRE to:

1. Navigate to the related table (e.g., cmdb_serial_number).
2. Search for a record matching the incoming serial number.
3. Trace the relationship back to the parent CI (the server) and return it as a match.

Identification vs. Reconciliation

It is important to distinguish between Identification Rules and Reconciliation Rules:

• Identification Rules: Establish who the CI is. They match the payload to a record.
• Reconciliation Rules: Determine what data sources are allowed to update specific attributes on that CI once its identity is established.

Reconciliation rules work in tandem with Data Source Precedence rules to prevent lower-authority sources from overwriting data provided by higher-authority sources (e.g., preventing a manual import from overwriting a real-time Discovery update).

Pre-execution Checks & Troubleshooting

During ingestion, the IRE enforces validation rules to prevent corrupting the CMDB:

• Mandatory Attributes: If an identifier entry requires a specific field (like serial_number), and that field is missing from the payload, the IRE skips that entry.
• Payload Verification: The incoming payload must conform to the class schema.

Administrators can use the Integration Commons and the IRE Input Payload Generator to simulate and test identification rules before executing them in production. This is crucial for verifying that custom discovery patterns or Service Graph Connectors do not create duplicate CIs.