CMDB identification and reconciliation
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
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
What does a reconciliation rule control?
- A. Which CI class is created
- B. Which data source may update an attribute
- C. Discovery schedule
- D. Relationship types
Show answer
B. Which data source may update an attribute
Reconciliation assigns attribute ownership to a data source.
Which write path bypasses IRE?
- A. Discovery
- B. CMDB API
- C. Direct GlideRecord insert on the CI table
- D. Service Mapping
Show answer
C. Direct GlideRecord insert on the CI table
Direct table writes skip identification, which is how duplicates appear.