ITOM deep-dive · LessonBy Neelima, ServiceNow Architect · Published · ServiceNow · all levels
CMDB identification and reconciliation
Stop duplicate CIs and control which source of truth may update which attribute.
Quick answer
Stop duplicate CIs and control which source of truth may update which attribute.
Key takeaways
- IRE is the gatekeeper for every CMDB write
- Identifier order defines match strength
- Reconciliation rules end the last writer wins problem
- Simulate payloads before enabling a new source
Identification rules
IRE decides whether incoming payload data matches an existing CI. Rules use identifier entries ordered by strength, for example serial number first, then name and IP. Get this right and duplicates disappear.
Reconciliation rules
When several sources report the same attribute, reconciliation decides who wins. Discovery may own operating system while an asset system owns location and owner. Without rules, the last writer wins and the CMDB becomes untrustworthy.
Working with it
Treat IRE as CMDB governance, not as a technical detail.
- Document which source owns which attribute before configuring rules
- Use the identification simulation to test payloads without writing data
- Watch the de duplication tasks queue, it is the early warning system
- Extend rules for custom CI classes rather than relying on name matching
Practice challenge
+0 XPStreak ×0
Question 1 of 2
What does a reconciliation rule control?
Frequently asked questions
Which sources go through IRE?
Discovery, Service Mapping, IntegrationHub ETL, the CMDB API and any integration that uses the identification engine. Direct table writes bypass it, which is why they should be avoided.
How do we clean existing duplicates?
Use the CMDB de duplication tasks with a remediation rule, and fix the identification rule first so the duplicates do not return.