ServiceNow identification rules are the criteria the platform uses to decide whether an incoming record describes a configuration item (CI) you already hold, or a new one that needs creating. They sit inside the Identification and Reconciliation Engine and run before anything is written to the configuration management database (CMDB). Get them right and two sources reporting the same server produce one record. Get them wrong and you get two records, or a hard error, or one record quietly overwritten by the other every twenty minutes for eight months.
Most CMDB duplicate problems are not discovery problems. They are identification rule problems that discovery made visible at scale.
Three parts, and the second one is where the trouble lives.
The rule is bound to a CI class, and it applies to that class and everything beneath it in the hierarchy. A rule on Hardware reaches Computer, which reaches Linux Server. This inheritance is useful and it is also how a rule written for one purpose ends up governing classes nobody was thinking about.
Inside the rule sit identifier entries. Each entry is a set of attributes evaluated together, and the entries are evaluated in priority order. An entry containing serial number and serial number type runs first. If that produces exactly one match, the engine stops and updates that record. If it produces nothing, the engine drops to the next entry, perhaps name and internet protocol address. If that produces nothing either, the record is new and gets created.
Then there are criterion attributes, which narrow the population an entry is allowed to search. Adding a location or a company to an entry means the engine only compares within that boundary. Two servers called WEB-01 can then coexist legitimately, one in Frankfurt and one in Slough, without fighting over the same record.
The engine takes the first entry that returns a single hit. Everything after that is unreachable for that record.
So an entry that matches loosely, placed high, will absorb records it should never have touched. We see estates where name sits above serial number in the priority list. The result looks like it is working, because names match often enough to keep the duplicate count down, right up until someone renames a host during a migration. At that point the engine finds no name match, falls through, and creates a second record. The old one keeps its incident history and its change records. The new one gets the patch data.
Nobody notices for a quarter, because both records look plausible in isolation.
The correct order follows how hard the attribute is to change. Serial number and serial number type are burned into hardware and survive a rebuild. A cloud instance identifier survives a rename. A hostname survives nothing. Put the durable identifiers first and the fragile ones last, and accept that the last entry will occasionally create a duplicate rather than pollute a good record.
Placeholder values treated as real ones. A source sends "To Be Filled By O.E.M." or a string of zeroes as a serial number. The engine matches it, finds forty existing records carrying the same string, and either throws an ambiguous match error or, worse, picks one. Every device with an unreadable serial converges on a single record. The fix is an inclusion rule that excludes those strings before identification runs, so the record falls through to a weaker entry instead of a wrong strong one.
Partial payloads from integrations. Horizontal discovery returns a full attribute set. A third-party integration often returns far less. If the rule expects a serial number or a stable external identifier and the payload carries neither, the record drops to the weakest entry every single time, and the integration generates duplicates at a steady rate that looks like a discovery fault.
We saw this on an estate running into the tens of millions of configuration items, where a cloud security posture tool had been adopted as the definitive source for cloud CIs. It exposed no unique identifier for elastic compute instances that could correlate to anything already in the CMDB. Every instance it imported duplicated one that horizontal discovery had already created.
The damaging part was not the duplication. Because the engine never recognised the pairs as matches, they never entered the de-duplication task queue, so the report everyone relied on to find duplicates showed nothing wrong. It surfaced when a cloud administrator noticed his instance count in the CMDB was double what his own console showed. By then change requests were being raised against the wrong records, which meant the impact analysis on those changes was wrong too. The fix was to stop importing compute instances from that tool and take them from the Service Graph Connector for Amazon Web Services instead, while leaving the rest of the tool's data in place.
Class mismatch on the way in. Identification is class-aware. A record arriving as Computer will not match an existing record stored as Linux Server unless the rule sits high enough in the hierarchy to cover both. Reclassification and identification interact here more than most teams expect.
Rules edited without a duplicate report first. If you tune a rule while the duplicates already exist, the new rule learns to match against a polluted population. On another estate, this one in the millions of configuration items, the team was confident the engine was preventing duplicates. It was not, and more than fifty thousand de-duplication tasks had accumulated unread. Clearing them took two analysts eight weeks, alongside an architect correcting the rules that had created them. The backlog was the evidence all along. Run the duplicate report first, grouped by serial number and by correlation identifier, resolve what it finds, and only then change the rule.
The engine exposes a way to run identification without committing the result, and this is the single most useful habit to build into your change process.
Construct a payload that represents the awkward case rather than the happy one. A record with a null serial number. A record whose hostname collides with an existing one in a different data centre. A record arriving from the integration you are about to switch on. Submit it, read what the engine says it would have done, and confirm that the outcome is the one you intended.
Then do the same against a record you know is a duplicate, and check whether your revised rule would have prevented it. A rule that cannot prevent the duplicates already in the database will not prevent the next ones either.
Log the results in the change record. When an auditor asks how you assured the CMDB after a rule change, this is the evidence.
Every new source is an identification event, not just an integration event. Before it writes anything:
| Question | Why it matters |
|---|---|
| Which attributes does it actually populate? | Determines which identifier entry it will ever reach |
| Does it send placeholders for missing values? | Decides whether you need an inclusion rule first |
| Which CI classes will it create? | Rules are class-bound; an uncovered class creates freely |
| Does it carry a stable external identifier? | Lets you match on correlation rather than guesswork |
| What happens on its second run? | Reveals whether it updates or duplicates |
Where a source has no identifier you can correlate on, a vendor-supported Service Graph Connector is usually the better route than a bespoke import, because the correlation is built into it.
Run the source into a controlled scope first, a single location or a single class, and read the duplicate report before widening. Then check that report is capable of seeing what the source creates, because duplicates the engine does not recognise as matches never get queued for anyone to find. A phased switch-on costs a fortnight. Reversing a source that created eleven thousand records costs considerably more, and the incident history it fragments does not come back.
We run a two-week CMDB health baseline that scores which of your configuration items are trustworthy and which are guesses. For identification specifically, that means reading your identifier entry priority order against your actual attribute population rates, running duplicate reports grouped by serial number and correlation identifier, and testing your live rules against the awkward payloads rather than the clean ones. The output is a scored report you can take to your change advisory board, naming which classes are safe, which rules are creating duplicates, and in what order to fix them.
Where the problem is broader than identification, we also run a data quality assessment against weighted critical success factors and measures, and a discovery and integration coverage review that establishes what is missing from your estate view and what it costs you during an incident. Both are scoped at the initial consultation against your requirements and your estate.
Two ways to start. Book a CMDB diagnostic call if you want a consultant to look at what you have, or book a meeting to talk through scope directly.
The engine treats the record as new and creates a configuration item. This is the correct behaviour, but it is also why weak identifier entries at the bottom of the priority list quietly generate duplicates rather than raising errors.
Because that queue is populated by the engine recognising two records as candidate matches. If the incoming source carries no attribute the rule can correlate on, the engine never treats the pair as related, and the duplicate is created cleanly without ever being flagged. A count reconciled against the source console will find these; the de-duplication report will not.
Yes, and they should. A network switch, a database instance and a cloud compute instance have almost nothing useful in common as identifiers. Rules inherit down the class hierarchy, so check what a rule on a parent class is reaching before you assume a child class is uncovered.
Because it survives events that destroy other identifiers. A host can be renamed, re-addressed, migrated between data centres and rebuilt, and the serial number stays constant. The exception is virtual infrastructure, where the hypervisor-assigned identifier is usually the stronger anchor.
Before. A rule tuned against a database that already contains duplicates will be tested against a corrupted population, and you will encode the existing problem into the new logic. Completeness and correctness have to be measured before they can be improved.
They apply to records submitted through the Identification and Reconciliation Engine. Records created directly in a table by a user with write access bypass identification entirely, which is one reason manual CI creation deserves a governance gate.