CMDB data quality depends on knowing which real asset a record describes, which source owns each attribute and how current that information is. Synchronizing more fields does not automatically improve those answers. Without reconciliation rules, faster integration can distribute conflicting data more efficiently.
The stakes rise when a CMDB record triggers an operational action. An incorrect owner might misroute a ticket; an incorrect device mapping might direct a remediation task to the wrong system. Start by defining trust at the field level.
Identity and authority solve different problems
Identification asks whether incoming data describes an existing configuration item. Reconciliation asks which source should be allowed to update a fact about it. A perfect asset match does not mean every attribute from the incoming source is authoritative.
ServiceNow’s Identification and Reconciliation Engine documentation describes a central framework that applies identification and reconciliation rules to incoming CMDB data. If your platform already owns that process, integrate through its supported path instead of introducing a competing writer.
Build an attribute ownership matrix
The following example is a proposed design for a fictional environment. Replace the choices with the owners and capabilities in your own systems.
| Attribute | Candidate authority | Rule to agree |
|---|---|---|
| Device identity | Trusted discovery or asset register | Use stable identifiers; investigate collisions. |
| Observed operating system | Current discovery source | Accept newer, valid observations. |
| Business service owner | Approved service register | Do not replace it with a logged-in user. |
| Support group | Maintained operating model | Change only through an approved mapping. |
| Lifecycle status | Asset lifecycle process | A missed scan alone does not prove retirement. |
| Cost center | Approved financial or asset source | Preserve ownership despite discovery updates. |
Do this for the attributes used by the first service, not every field in the CMDB. A narrow, reliable set is enough to start testing a specific automation.
Example: a laptop appears under a new hostname
A discovery system reports a laptop with a new hostname but the same trustworthy device identifier. The asset register contains a business owner, while the latest observed user is a contractor. Simply overwriting the record with the newest payload would confuse observed usage with ownership.
The proposed workflow first resolves identity. It then updates only the fields that the discovery source owns, retains the approved business owner and records the observation timestamp. If the identifiers conflict, it creates a review item rather than a duplicate record.
When the device stops reporting, mark its freshness state according to policy. Do not automatically retire or delete it unless the lifecycle process provides the necessary evidence. The device could be offline, replaced or temporarily unreachable.
Make conflicts inspectable
A useful conflict record includes the competing values, their sources, observation times and the rule that prevented an automatic update. An operator should be able to resolve the issue without reconstructing a sequence of integration logs.
Distinguish a value that is unknown from one that was intentionally cleared. Treating both as an empty string can erase maintained data. Likewise, keep source observation time separate from import time: a record imported today may describe an observation from last month.
For repeated or out-of-order deliveries, use the agreed freshness and ownership rules. “Last payload received wins” is rarely a sufficient business policy for service ownership, lifecycle or access decisions.
Put a quality gate before a consequential action
Suppose a workflow needs to restart a managed service on an endpoint. Require the device mapping, customer context and support ownership needed for that action. If any are ambiguous or stale beyond the agreed threshold, route the request to review.
Not every missing field should stop every automation. A missing cost center may be irrelevant to a diagnostic read but important to procurement. Define the minimum evidence for each service instead of claiming the whole CMDB is either “trusted” or “untrusted.”
A small reconciliation pilot
- Select one asset class and the attributes used by one workflow.
- Sample current records and classify duplicates, stale observations and ownership conflicts.
- Agree identification, precedence and freshness rules with source owners.
- Run a comparison before enabling updates; inspect proposed changes.
- Enable a limited scope and review conflicts with a named owner.
- Measure improvements against the same sample and workflow requirements.
Measure the percentage of in-scope records meeting the service’s quality rules, unresolved conflict age and manual correction effort. A rise in imported records says little about whether the next operational decision will be correct.
Where Autom Mate fits
Autom Mate’s CMDB integration capabilities can connect the surrounding sources and service workflows. The ownership matrix and supported reconciliation path should determine what those integrations are permitted to change.
Bring two conflicting source records to a workflow session. We can map the required identity checks, field ownership and exception route before connecting the data to an operational action.
