Getting Started with Reconciliation

Reconciliation keeps your CMDB clean at the moment data arrives: it matches each incoming Configuration Item against the ones you already have, so a second source reporting the same device updates the existing Configuration Item instead of creating a duplicate.

This guide takes you from a switched-off feature to your first resolved match, then shows you how to work the queue and tune matching. If you are standing up Asset Management from scratch, start with Getting Started with Asset Management first, then come back here.

The problem it solves

Every discovery tool, integration, and import that feeds your CMDB is a separate source of truth. Connect two of them and, without reconciliation, the same laptop lands twice: once from the discovery scan, once from the MDM sync. Those duplicates then distort every count, report, and impact analysis downstream.

Reconciliation sits in front of the CMDB and intercepts incoming Configuration Items from those sources. It searches for a matching Configuration Item, scores how confident the match is, and either resolves it automatically or parks it for a reviewer to decide. A strong, unambiguous match updates the existing Configuration Item. Anything uncertain waits for a person.

Before you start

• Reconciliation is turned on. This is the single most common reason a customer sees nothing happen. Reconciliation only runs when "Enable CI Reconciliation" is checked in the account settings, under "Configuration management".
• At least one ingestion source is connected. Reconciliation only acts on data arriving through an ingestion path: discovery, an integration app (for example Microsoft Intune or Jamf), an import, or the ingest API. Changes made by hand in the interface or through a direct API edit bypass reconciliation entirely.
• You already have Configuration Items to match against. Reconciliation resolves incoming records against your existing CMDB. On a completely empty CMDB the first sync has nothing to match, so every record is net new. The value shows the second time a device is seen.
• You have the Configuration Manager role. Reviewers need it to act on parked records.

Turn reconciliation on

In the account settings, under "Configuration management", check "Enable CI Reconciliation".

Turning it on changes how the CMDB guards Configuration Item uniqueness. The queue becomes the integrity check for incoming data, so the previous hard block on duplicate serial numbers relaxes in favor of the matching engine. This is expected. It is what lets a second source resolve to an existing Configuration Item rather than being rejected outright.

Connect a source that flows through reconciliation

Point an ingestion source at your CMDB. An iPaaS connector such as Microsoft Intune or Jamf is the best first source, because those feeds carry the fields that make matching work well, including serial number and asset tag.

To connect Microsoft Intune, follow Intune CMDB. For other connectors, see Integrations.

A note on discovery-only sources. Records that arrive from a raw discovery scan carry a thinner field set, typically name, serial number, and hardware specifications, without an asset tag. Those records can still match on serial number, but the asset-tag matching described below needs a source that sends one, which is why a connector feed is the stronger starting point.

See your first match resolve

Once the source runs, open the Reconciliation Queue in the Asset Management navigation.

The clearest proof that reconciliation is working: connect a second source for a device you already track, and watch the incoming record resolve to the existing Configuration Item by serial number instead of creating a new one. Your Configuration Item count does not move, and the existing record picks up whatever fresh values the new source reported.

Everything below is about handling the records that cannot resolve that cleanly on their own.

Work the parked queue

Not every incoming record has an unambiguous match. When the engine cannot resolve one on its own, it parks the record at one of three statuses and waits for a reviewer:

• Needs identification: the engine has not found a confident match and needs a person to identify the right Configuration Item, or confirm there is none.
• Needs review: a Configuration Item has been resolved and the proposed changes are waiting for a reviewer to approve them.
• Ambiguous match: two or more candidates matched, and the engine cannot tell which existing Configuration Item is the right one.

Filter the queue to Parked to see everything waiting on you.

Open a parked record to work it in the reconciliation modal, which has two panels. The Identify panel runs while a record is still being matched: it lists candidate Configuration Items with their confidence scores, lets you search your own Configuration Items to link one by hand, and offers Create as new CI when the incoming record genuinely is a new asset. The Review panel runs once a Configuration Item is resolved and shows a current-versus-proposed field comparison, so you can see exactly what the update would change before you accept it.

From the Review panel you have three ways to finish a record: apply the proposed values to the matched Configuration Item, accept the record as a new Configuration Item, or dismiss it with no change. If you resolved a record to the wrong Configuration Item, Back to identification returns it to matching so you can try again.

Tune matching with rules

Once you have watched a few records flow through, you will want the engine to handle more of them without a reviewer. That is what reconciliation rules are for: they let you auto-resolve the cases you trust and escalate the ones you do not, using your own data. Start with the defaults, watch the queue for a week, then add rules where you see the same manual decision repeating.

See Reconciliation Rules for the full set of triggers and conditions.

How this shows up on the CMDB Health dashboard

The CMDB Health dashboard is where the payoff becomes visible over time. Until reconciliation is running, its duplicate tiles read Detection not configured rather than No data available, which is your signal that the capability is off, not that your data is clean. Once reconciliation is on and a source is feeding it, the duplicate tiles begin reflecting real candidate activity, and check-in freshness moves as sources report.

If a tile says Detection not configured, the next action is this guide: turn reconciliation on and connect a source.

If nothing appears in the queue

• Reconciliation is off. Re-check the setting. This is the most frequent cause.
• The change did not come through an ingestion source. Edits made by hand in the interface or through a direct API call do not enter reconciliation by design. Only discovery, integrations, imports, and the ingest API do.
• The source sent nothing new. Check the source's own execution summary for the count of records received since the last run.
• The records had no field to match on. A discovery-only source without serial numbers or asset tags gives the engine little to work with. Confirm the source is mapping serial number.