1. Help
  2. Asset Management & CMDB
  3. Reconciliation
  4. Reconciliation Rules
  1. Help
  2. Asset Management & CMDB
  3. Reconciliation
  4. Reconciliation Rules
purple icon for coordination.
We’ve moved!
Our Help Center has a new home and our URLs have changed. Please update your bookmark to this page before April 30, 2026

Reconciliation Rules

Auto-resolve trusted matches and escalate uncertain ones.

Reconciliation rules let you tune how the matching engine behaves on your own data: auto-resolve the cases you trust, escalate the ones you do not, and keep reviewers focused on the records that genuinely need a decision.

If you are new to the feature, read Getting Started with Reconciliation and The Reconciliation Queue first.

The two rule types

The Reconciliation Rules tab splits into two kinds of rule, matching the two phases of the pipeline:

  • Identification rules shape how incoming records are matched to Configuration Items.
  • Review rules act on records once a Configuration Item has been resolved, for example to auto-approve a trusted update or hold a sensitive one for a person.

Triggers

Rules react to what the engine does at each phase. Four triggers are available:

  • On identify: a record has entered identification.
  • On matched: a single confident match was found.
  • On unmatched: no match was found.
  • On ambiguous: two or more candidates matched.

This lets you write logic like "auto-resolve on a confident serial match" or "escalate anything ambiguous to a specific team."

What a rule can read

In a rule's conditions, you can read the matches the engine produced:

  • matched_cis: the candidate Configuration Items for the record.
  • For each candidate: its confidence score, what it matched_on, and the ci it points to.

Because the confidence score and match basis are available to rules, you can tune matching to your own tolerance: auto-resolve above a confidence threshold, require review below it, or treat a specific match basis as always trustworthy.

Auto-resolving matches

Auto-resolve is opt-in. Records do not resolve themselves by default; you enable it with a review rule. To keep the CMDB safe, only strong, hard-identity matches are eligible to auto-resolve, so a weak signal always surfaces as a candidate for a person rather than merging silently, even at high confidence.

Starter behavior

Out of the box, the engine matches on a small set of signals so you see useful behavior before writing any rules:

  • Serial number produces a strong match and can resolve automatically.
  • Asset tag and name plus type surface as candidates and park for review rather than resolving on their own.

Start with these defaults, watch the queue for a week, and add rules where you notice the same manual decision repeating. Expand deliberately: a rule that auto-resolves too aggressively is harder to unwind than a queue that is slightly too full.