CMDB Identification and Reconciliation Engine fundamentals<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Learn the key concepts of the CMDB Identification and Reconciliation Engine (IRE), including identification rules, reconciliation rules, dependent relationships, deduplication, reclassification, and available tools. This article provides a foundational overview for administrators and platform engineers working with the CMDB. In this article IRE overviewIRE componentsIndependent and dependent CIsDuplicatesReclassificationPartial itemsIRE flowIRE toolsCleanupProperties IRE overview The Identification and Reconciliation Engine (IRE) is a centralized framework that processes payloads to maintain the Configuration Management Database (CMDB). The IRE handles the creation of new configuration items (CIs) and updates to existing CIs. Without a centralized framework, multiple sources updating the CMDB with independent logic can lead to duplicate CIs, undesired updates, and attribute flapping (multiple sources continuously updating the same fields with different values). The IRE prevents these issues by providing a single framework that keeps the CMDB free of duplicates and maintains the most relevant data. Note: There is no built-in logic to block direct updates to the CMDB that bypass the IRE. However, by updating the CMDB directly, you lose the benefits of using the IRE. All updates to the CMDB should be made through the IRE IRE components Identifier An identifier is a set of rules for a class that the IRE uses to determine if a CI already exists in the CMDB. If a class does not have an identifier, it inherits one from the class hierarchy. For example, most classes in a child branch from cmdb_ci_hardware inherit the Hardware identifier. Identification rules The IRE uses identification rules to find CIs in the CMDB. Each identification rule contains a set of attributes used to search the CMDB for a match. The IRE analyzes the incoming payload and applies the identification rules in priority order to find an existing CI. If no match is found, the IRE creates a new CI. Inclusion rules Inclusion rules narrow the scope of which CIs are included in the identification process. CIs that do not match the criteria set by the inclusion rules are excluded from IRE processing. The IRE first applies the identification rules to find CIs in the CMDB, and then applies the inclusion rules to determine if those CIs can be used. For example, if retired Windows Server CIs in the CMDB should no longer be updated by data sources, an inclusion rule can prevent the IRE from updating those records. However, inclusion rules can lead to duplicate CIs if not configured properly. Note: Configuring an inclusion rule to exclude CIs by class leads to duplicates. For more information on identification rules, inclusion rules, and how to configure them, see Identification rules. Reconciliation rules The IRE uses reconciliation rules to determine which data sources should be prioritized. The data source with the highest priority determines the attribute value. This prevents less reliable data sources from overwriting fields in a class. Without reconciliation rules, data sources would overwrite each other's updates. For more information on reconciliation rules, including the differences between dynamic and static rules, see Reconciliation rules. Data refresh rules If a high-priority data source stops sending updates for a CI, the data may become stale over time. Data refresh rules specify when CI data is considered stale. When this threshold is met, other allowed data sources with lower priority can update those CIs. Note: Data refresh rules have no impact when dynamic reconciliation rules are in effect. Data refresh rules are used only with static reconciliation rules. For more information, see Create a data refresh rule. CMDB 360 CMDB 360 retains a complete history of discovery sources and proposed values involved in CI attribute updates. Use CMDB 360 data to: Track how the CMDB is populated by various discovery sources at the CI attribute levelRevert CI updates from a specific discovery sourceRecompute attribute values using updated reconciliation rules CMDB 360 provides all the functionality of the legacy Multisource CMDB feature with additional capabilities such as an analytics dashboard and query functionality. For more information, see CMDB 360. Independent and dependent CIs CI dependency is specified in CI Class Manager through the dependent relationship rules for the CI's class. Independent CIs — CIs, such as Server CIs, that exist on their own and are not dependent on any other CIs.Dependent CIs — CIs that depend on a relationship to another CI and cannot exist on their own without the dependent relationship. For example, Network Adapter CIs cannot exist meaningfully without the Hardware CIs that contain them, and Application CIs cannot exist without the Server CI they are hosted on. The following image shows the dependent relationships for the Tomcat class. Tomcat payloads must include a Runs on relationship to a Hardware CI. The identification process for dependent CIs differs from the process for independent CIs. The IRE returns an error if a dependent CI payload does not include the required relationships. To verify that your payload includes all required components, use the identification simulation. For instructions, see How to build and troubleshoot an IRE payload for CMDB. Identifier types Independent identifier — Identifies a CI based on the CI's own attributes, independently of other CIs or relationships.Dependent identifier — Requires identifying an independent CI first. A CI can have dependency on one or more CIs, and a dependent CI can have only a single parent CI with dependency. The relationship types between the CI and its dependent CIs are included in the identification process. To support the identification of dependent CIs, create dependent relationships that define the dependency chain within CI types. The payload used for identification of a dependent CI can include a relationship with a qualifier chain. For such a relationship, if there is a matching parent/child pair, the system compares the qualifier chain in the payload with the qualifier chain of the CIs in the database. If there is a difference, the qualifier chain in the database is updated to match the qualifier chain in the payload for that relationship. The following image shows the identification simulation being used to build a payload. The generated payload includes: An independent CI (cmdb_ci_win_server)A dependent CI (cmdb_ci_network_adapter)The required Owns::Owned by relationship for the Network Adapter Duplicates When the IRE API is called, it may find duplicates. If duplicates are found, the IRE creates a deduplication task. For information on using deduplication tasks to resolve duplicate CIs, see the following resources: Review de-duplication tasks (manual)Remediate a de-duplication task (manual)Manually create a de-duplication taskDetecting duplicate CIs For troubleshooting duplicate CIs, see How to troubleshoot duplicate CMDB CI records. Duplicates may also be found by the CMDB Health Correctness job. For details, see CMDB Health — Duplicate Metric algorithm. Reclassification CIs can be reclassified by upgrading, downgrading, or switching their class. Upgrade (moves up the hierarchy) — For example, Server → Windows ServerDowngrade (moves down the hierarchy) — For example, Linux Server → ServerSwitch (moves to a different branch of the hierarchy) — For example, Printer → Switch Warning: Avoid CI class downgrade and CI class switch operations, as they can lead to data loss. When automatic CI reclassification is enabled (the default setting), the identification process can result in automatic reclassifications that cause data loss. Data for fields that do not exist on the target class is lost. For more information and properties that control reclassification behavior, see Configure CI reclassification during IRE processing. Partial items A payload item is determined to be a partial item if it contains the necessary data for unique identification and has one of the following errors. Unique identification requires that the payload item has the sys_object_source_info section with source_name and source_native_key values, the full set of identification criterion attributes specified for the CI class, or both. IRE errors for a partial item: MISSING_MATCHING_ATTRIBUTES — Item does not have identification criterion attributes to use at least one identifier entry for matching.REQUIRED_ATTRIBUTE_EMPTY — Unable to create a CI because a required attribute is missing.MISSING_DEPENDENCY — Dependent CI is missing a dependency relation specified in the payload.INSERT_NOT_ALLOWED_FOR_SOURCE — An IRE data source rule prevents the specified data sources from creating CIs of the specified class. If processing fails because payload items are determined to be partial items, the IRE saves them as partial payloads in the CMDB IRE Partial Payloads [cmdb_ire_partial_payloads] table in JSON format for later processing. The IRE uses identifier keys to attempt to match incoming payloads with stored partial payloads. If a data source later sends the missing data, the IRE matches the incoming payload with the stored partial payloads and merges them. To resolve conflicting attributes, the IRE uses either source_recency_timestamp (when source_native_key and source_name are identical) or static reconciliation rules specified for the class. The result is a complete and valid payload that the IRE processes to create or update the respective CIs. Partial payloads older than 90 days are deleted from the [cmdb_ire_partial_payloads] table. IRE flow For a detailed walkthrough of how the IRE processes a CI payload through each stage, see How the CMDB Identification and Reconciliation Engine processes a CI payload. IRE tools CI Class Manager CI Class Manager is the central location for configuring IRE rules and settings. To open CI Class Manager, go to Configuration > CI Class Manager. The following image shows CI Class Manager and the identification rules and inclusion rules configuration for the Windows Server class. Identification simulation To open the identification simulation, go to Configuration > Identification/Reconciliation > Identification Simulation. For instructions on using the identification simulation to build IRE payloads, see How to build and troubleshoot an IRE payload for CMDB. Debug Identification and Reconciliation For information on debugging the IRE, see How to debug the Identification and Reconciliation Engine using background scripts. For a complete list of IRE errors, see IRE error messages. Cleanup For information on how to identify and delete duplicate CMDB CI relationship records or records with orphan or missing parent/child relationships, see How to identify and delete duplicate CMDB CI relationship records. Properties For a comprehensive list of IRE properties, see Properties for Identification and Reconciliation.