OBLYTECH / SERVICENOW CAPABILITY
ServiceNow CMDB reconciliation and duplicate control
Define identity, source precedence, duplicate review, conflict handling and evidence before automated clean-up.
PARTNER DELIVERY — OBLYTECH is a ServiceNow Partner.
Discuss your reconciliation priorityServiceNow CMDB reconciliation is not simply a merge operation. It is a decision about
whether records describe the same configuration item, which source should be trusted,
what happens when values conflict and when a person must review the candidate. OBLYTECH
helps teams define those rules before automated clean-up changes operational meaning.
Resolve identity before correcting records
A record can look similar to another record while representing a different environment,
service or lifecycle state. Matching should therefore use evidence that the responsible
team understands, not only a convenient text comparison. The rule should explain why
two records are considered the same and what uncertainty remains.
The rules behind safe reconciliation
Identity and matching evidence
Define the identifiers, attributes and source evidence used to establish identity. State
which fields are stable, which can change and how missing information affects confidence.
A low-confidence candidate should go to review rather than being merged silently.
Source precedence and conflicts
When sources disagree, define which source owns the value and who resolves the conflict.
Precedence should be specific to the data and decision; one source may be authoritative
for an identifier while another owns lifecycle information.
Duplicate review and exceptions
Duplicate candidates need a queue, reviewer, evidence and outcome. Preserve an exception
when the records are intentionally separate, and record the reason so the same candidate
does not return without context.
How OBLYTECH approaches reconciliation
- Identify the operational decision and records it depends on.
- Map identifiers, sources, fields, precedence and current exceptions.
- Define matching confidence, review thresholds and permitted actions.
- Test same-item, similar-item, missing-data and conflicting-source cases.
- Establish evidence, remediation ownership and review cadence.
For the parent route, see ServiceNow CMDB, CSDM and ITAM.
For the wider platform route, see ServiceNow services overview.
What the engagement can establish
- identity and matching rules;
- source precedence and conflict ownership;
- duplicate review and exception paths;
- permitted automated actions; and
- evidence for reconciliation decisions.
Discuss your CMDB reconciliation priority
Bring the record conflict, duplicate pattern or source disagreement that is creating
operational uncertainty. OBLYTECH can help define a reconciliation control that keeps
automated action bounded and human review meaningful.
Discuss your CMDB reconciliation priority
Bring the record conflict, duplicate pattern or source disagreement creating operational uncertainty.
Discuss your CMDB reconciliation priority with OBLYTECHThe question to answer before switching on automated merging
Automated reconciliation is attractive because duplicates are visible and tedious to clear by hand. The risk is that a merge changes the record that every other process relies on. Once two records are combined, the history of each may be harder to separate, and a relationship that pointed to one of them may now point to the wrong thing. Before a rule is allowed to act without review, the team should be able to answer one question for each permitted action: if this decision is wrong, how will we see it and how will we reverse it?
That question sets the boundary. A rule that can be reversed, and whose wrong decisions surface quickly in normal operation, is a candidate for automation. A rule whose mistakes would stay hidden until an audit or a major incident is a candidate for review only, however confident the matching logic appears.
Matching outcomes and the action each one permits
Matching produces a confidence assessment rather than a binary answer. The table below sets out a common way to decide what happens at each level. The thresholds are a design choice to be agreed with the record owners, and the values themselves should be tested against sample records before they are used.
| Match outcome | Typical evidence | Permitted action |
|---|---|---|
| Same item, strong stable identifiers agree | Serial number, unique hardware identifier or a verified cloud resource identifier, with compatible class and location | Reconcile automatically, with the merge logged and reversible |
| Probable same item, some identifiers missing | Name and address match, but a stable identifier is absent on one side | Queue for a reviewer with both records side by side |
| Similar but different items | Same model and site, different serial numbers or different lifecycle states | Keep both, record that they are distinct, and suppress the candidate |
| Conflicting authoritative sources | Two sources hold different values for an identifier that should be unique | Hold the change, escalate to the owner of the authoritative source |
The second row is where most value and most risk sit. A reviewer should be able to see the evidence on both sides, and the review should not become a rubber stamp. If reviewers approve nearly every candidate in a queue, the threshold is probably too low for automation and the team should reconsider what it is asking reviewers to decide.
Identifiers that can anchor a match
Not every attribute is equally stable. Some identifiers are issued once and do not change; others are reassigned, renamed or copied from templates. A reconciliation rule should state which fields are treated as anchors, which are supporting evidence, and which must never decide a match alone.
- Anchors: unique identifiers issued by a manufacturer or a cloud platform, where the value is verified against the source and not typed by hand.
- Supporting evidence: names, locations, owners and network details, which change more often and are frequently wrong in manual entries.
- Never decisive alone: a hostname or a display name, because names are reused across environments and rebuilt systems.
- Missing data: treated as lower confidence, not as a neutral value, so an absent identifier cannot make two records look more alike.
Virtual and containerized resources deserve particular care. Their identifiers may be ephemeral, and a rule that matches on them can merge records that describe different workloads over time. The rule should say whether identity is tied to the resource, to the workload it runs, or to the service it supports.
Reversing a wrong decision
Reconciliation should be planned with its own failure in mind. Before a rule goes live, the team should be able to point to the record of each merge, the values each source contributed, and the relationships each record carried. Without that trail, a wrong merge becomes a manual reconstruction. The practical test is to take one merged record and explain, from the logs alone, how it got its current values. If the explanation needs the memory of the person who ran the job, the audit trail is not good enough.
Reversal also needs a decision. Some wrong merges can be split cleanly. Others have already changed downstream records, such as an incident linked to the merged item, and the correction must address those links as well. Agree in advance which downstream records are checked after a reversal, and who signs off that the service view is correct again.
Intentional duplicates and how to keep them
Some records look like duplicates because they are meant to. Two instances of the same application in different environments, a primary and a standby device, or a shared template used by several teams can all trigger a candidate match. Without a way to record that they are distinct, the same candidate returns after every discovery cycle, and reviewers learn to dismiss it without reading.
A distinctness decision should record the reason, the people who agreed it and the condition that would bring the candidate back for review, such as a retirement of one of the environments. That record turns a recurring nuisance into a settled and traceable decision.
What reconciliation cannot correct
Reconciliation works on the records that exist. It cannot establish records that discovery never found, and it cannot decide which of two correct values a service should show if the service owner has not confirmed the boundary. A duplicate report that is clean after reconciliation may still be incomplete.
Duplicates also reflect lifecycle decisions that were never made. An asset retired on paper but still present in the configuration data will often look like a duplicate of its replacement. The hardware, software and cloud asset lifecycle page looks at the decisions that change, transfer, renew or retire an asset, which is usually where those cases are better resolved than by merging them.
The CMDB data quality and governance page connects quality rules to named owners, remediation work, exceptions and review evidence, and the CMDB ownership model page looks at who decides and who corrects CMDB data.
Questions to resolve before enabling a merge rule
Can we start with reviewed merges and move to automation later?
Yes, and it is usually the safer route. Running a rule in review-only mode for a period shows how often reviewers agree with its proposals. Automation should be enabled only for the outcome categories where that agreement is consistently high and where a wrong decision would be reversible.
What evidence should a reviewer see?
Both records side by side, the identifiers each one holds, the source of each value, the relationships attached to each record, and the reason the rule proposed the match. A reviewer who sees only the proposed merged result cannot judge whether the merge is correct.
How do we handle a merge that was wrong for a long time?
Treat it as an incident in the data. Establish which downstream records relied on the merged item, correct those first, and then reverse the merge. Record the cause so the rule that allowed it can be tightened.
Does reconciliation replace a clean-up project?
No. Reconciliation can help stop new duplicates from forming and sorts candidates for review. Existing duplicates still need a one-time decision for each cluster, and that decision is usually faster when the rules are already defined.
If duplicate candidates are piling up faster than anyone can review them, or a recent merge is now causing confusion in the service view, the fastest fix is usually to take one candidate family and the rule that produced it, and look at both together. Contact OBLYTECH and bring a sample of recent candidates with the records that were kept and the ones that were separated.
A worked example of reconciling one server that three sources report
Reconciliation is easiest to see with one device. A physical server is found by network discovery, imported again from an asset inventory, and typed in by hand years ago by an engineer who has since left. Without rules, that is three configuration items. With rules, it should be one record, with each attribute coming from the source best placed to know it.
| Attribute | Best source | Why |
|---|---|---|
| Serial number | Discovery or the asset inventory | Read from the device, not typed |
| Operating system and version | Discovery | Changes with patching, and only discovery sees it |
| Owner and cost centre | Asset or finance data | A business decision, not something a scan can observe |
| Name | The record owner | Names are reused, so no source should overwrite it silently |
The sequence that gets there is the same on every site:
- List every source that can create or update the class, and who owns each one.
- Choose the identifiers that decide a match, and write down which are anchors and which are only supporting evidence.
- Decide, attribute by attribute, which source wins when two disagree.
- Run the rules in review-only mode against a sample and read the proposals that look wrong before changing anything.
- Switch on automatic action only for the match outcomes where reviewers almost never disagree.
- Watch the duplicate count and the review queue each cycle, and retune when either drifts.
“Consolidation” is a related but separate job. Reconciliation removes duplicates inside one set of records. Consolidation merges the sources feeding that set, for example two discovery tools or a retired asset system, and it needs the same precedence decisions agreed before any data moves. A step skipped here usually returns as duplicates a month later.
To judge whether the rules are working, the CMDB KPIs and metrics page lists the measures worth tracking. The way discovery finds records is covered in discovery and service mapping, and the effect of class choice on matching is explained in CMDB class explained.
ServiceNow guides on this topic
Guides from the Oblytech ServiceNow library that explain the practice behind this page.