Skip to main content

Submitting Analysis and AutoMerge Requests

Everything else in this guide (connections, entity definitions, matching, ranking, precision) exists to make a request possible. The request is what actually runs.

The three-step cycle​

Duplicate cleanup is not one operation. It is two service requests with a human judgment between them, and that middle step is not optional.

1. Analyze/Tag​

You submit a request with Operation = Analyze/Tag. The service reads your CRM through the CRM connection, applies the configuration's FetchXML filter, matching rules, ranking rules, and precision rules, and writes the results back into your CRM as tagged duplicate sets.

Nothing is merged. Records are grouped, ranked, and scored. That is all.

2. Human validation​

You, or the people who own the records, review what came back, inside your own CRM.

This is where you find out whether your rules mean what you thought they meant. Sets that look wrong are usually a matching rule that is too loose, a ranking rule that picks the wrong winner, or precision weights that don't reflect how identity actually works in your data. Adjust the configuration and run another Analyze/Tag pass.

Start in the dupes list views, work the high-precision end first, and use AutoMerge Set Primary and AutoMerge Ignore to correct individual sets as you go.

Do not skip to step 3

An AutoMerge request executes merges in bulk, and merges cannot be undone, not by AutoMerge and not by Dynamics' native merge. The only defense against a bad rule is having looked at its output first.

3. AutoMerge​

Once you trust the tagged results, you submit a second, separate request with Operation = AutoMerge. The service merges the already-tagged sets in bulk.

Merging is filtered by a minimum precision threshold, which defaults to 100%, so only the highest-confidence sets are merged unless you deliberately lower it. Work downward from there as your confidence in the rules grows.

This step covers what's possible from the Management App: a bulk request across every tagged set above your threshold. AutoMerging can also happen directly inside the CRM: in bulk from a dupes list view, or one set at a time from the Potential Duplicates subgrid on a record's form.

Following a request​

Every request has a Status Updates tab: a chronological log of processing steps, written as the service works. For AutoMerge operations it also carries an estimated completion time.

That tab is where you look when a request seems slow, and what you send us if you need help with one.

What to expect for scale​

Demo reference~9,000 Contacts analyzed, ~1,700 duplicates tagged, about 5 minutes
Large CRMsThe service handles tens of millions of records; it simply takes longer
Merge requestsCan run for hours; see request scheduling

Maximum Duplicate Set Size​

Requests carry a Maximum Duplicate Set Size, default 20. It caps how many records the tagging step will place in a single duplicate set.

When a genuine duplicate group is larger than the cap, tagging splits it into several sets of at most that size. Those sets merge normally, and the surviving winners get caught as a new set on the next Analyze/Tag pass.

This matters mainly as the lever for resolving timeouts. See Timeout errors.

Practical sequence for a new configuration​

  1. Point the request at a Sandbox connection.
  2. Analyze/Tag with a narrow FetchXML filter.
  3. Review the precision distribution on the dashboard.
  4. Adjust rules, re-run, compare.
  5. Widen the filter; repeat until the output stops surprising you.
  6. Move to Production, Analyze/Tag, validate.
  7. AutoMerge at 100% precision. Lower the threshold only as your confidence justifies it.