How IRE Protects Your ServiceNow CMDB

Why duplicates appear

Duplicates usually begin when integrations identify the same device differently. Discovery may use a serial number, an asset feed may use a name and a cloud connector may use a provider ID. If each source inserts directly into a CI table, three records can represent one real machine.

The problem is bigger than an untidy list. Incidents, changes, relationships and service maps can point to different copies of the same CI. Reports become unreliable and operational teams lose confidence in the CMDB.

Identification comes before reconciliation

Identification asks one question: does this incoming payload describe a CI that already exists? Identification rules compare reliable attributes in a defined order. A computer might first be checked by serial number and serial number type, then by another trusted combination when the first identifier is unavailable.

Reconciliation begins only after the correct CI is found. It controls which source may update a particular attribute. Discovery may be authoritative for operating system details while an approved business feed owns support group or business context.

• Choose identifiers that are stable and genuinely unique.
• Avoid using display names as the only identifier.
• Define source precedence before connecting multiple data providers.
• Send integrations through IRE instead of inserting directly into CI tables.

What good governance looks like

IRE is a guardrail, not a replacement for governance. Review identification rules when new data sources are introduced, monitor duplicate tasks and investigate why required identifiers are missing. A recurring duplicate is usually a process or source-data problem, not simply a record to delete.

Start with one important CI class, document its trusted sources and test create, update and duplicate scenarios. Once the behaviour is predictable, expand the same discipline to other classes. A trusted CMDB grows through controlled decisions, not a one-time cleanup.