Duplicate CIs are two or more CMDB records that represent the same real-world configuration item. They damage trust because incidents, changes, security findings, ownership, and service relationships may attach to different copies of what should be one object.<\/p>\n
CIS-DF expects candidates to understand why duplicates are created, how CMDB Health and IRE help identify the problem, how deduplication tasks are remediated, and\u2014most importantly\u2014how to prevent the same duplication pattern from returning.<\/p>\n
Duplicates can come from weak identification rules, missing identifiers, inconsistent source data, imports that bypass IRE, manual CI creation, or multiple integrations that identify the same object differently. The visible duplicate is often only the symptom.<\/p>\n
Before remediation, determine how each record was created and which source will continue to send updates. Otherwise a clean merge today can be followed by a new duplicate tomorrow.<\/p>\n
IRE uses identification rules to determine whether incoming data matches an existing CI. If a rule is too weak, several records may appear to match. If it is too strict or uses unavailable attributes, the engine may fail to match the existing CI and create another one.<\/p>\n
Review identifier quality, priority, and data availability for the affected class. The best remediation combines record cleanup with a rule or ingestion fix.<\/p>\n
Duplicates contribute to the correctness dimension of CMDB Health. Dashboards and health results can show which classes have duplicate issues and provide a way to prioritize remediation.<\/p>\n
A class with a high duplicate rate deserves upstream investigation. If duplicates cluster around one integration or CI type, that pattern is more useful than the overall CMDB score.<\/p>\n
ServiceNow can create deduplication tasks when duplicate groups are detected. The remediation process identifies the records that represent the same real-world object and determines which record should survive as the primary CI.<\/p>\n
Selection should consider data quality, source history, relationships, ownership, and operational references. The oldest record is not automatically the best record in every real environment, so administrators need to understand the data before confirming the merge strategy.<\/p>\n
Duplicates often accumulate different relationships. One record may be attached to incidents, another to a service map, and another to discovery data. Remediation must preserve the relationships and references that still represent reality.<\/p>\n
This is why duplicate cleanup is not the same as deleting extra rows. The surviving CI should become the authoritative object for downstream processes.<\/p>\n
If multiple sources continue to update the same CI, reconciliation rules should define which source owns important attributes. Otherwise a deduplicated record can remain unstable because competing integrations overwrite each other.<\/p>\n
Identification and reconciliation are complementary: identification stops duplicate creation, while reconciliation protects the quality of the consolidated record.<\/p>\n
Different sources may represent the same identifier in different formats. Serial numbers, hostnames, cloud identifiers, and names may include prefixes, case differences, or formatting variations. Normalization can improve matching when those differences are predictable.<\/p>\n
Normalization should be designed carefully so distinct values are not collapsed accidentally. It should support true identity, not manufacture matches between unrelated objects.<\/p>\n
Manual creation can be useful, but it can also bypass the data-quality controls built into automated ingestion. Governance should define when users are allowed to create CIs manually, which classes require approval, and which identifiers must be populated.<\/p>\n
Training matters as well. If teams do not know that an existing CI can be searched or updated, they may create a new record whenever they cannot immediately find the old one.<\/p>\n
After duplicates are remediated and rules are changed, send representative source data through the normal integration path. Confirm that it updates the intended surviving CI and does not create another record.<\/p>\n
Regression testing is particularly important when identification rules are shared across many sources. A change that fixes one integration should not break another.<\/p>\n
A cleanup project can make the dashboard look better temporarily. Sustainable success means the rate of new duplicate creation declines and remains low. Trend health metrics, deduplication-task volume, and source-specific errors over time.<\/p>\n
This turns duplicate management from periodic firefighting into a controlled data-quality process.<\/p>\n
Duplicate tasks are resolved faster when classes and records have clear owners. Data stewards and managed-by groups should know which teams are responsible for validating records, source behavior, and relationships.<\/p>\n