Timeout Errors
Timeouts are the most common problem people hit, and they are almost always solvable by changing one setting.
Why they happen
Processing time for a merge comes down to two things:
- How many records are in the duplicate set.
- How many related records must be repointed to the winner: opportunities, activities, connections, activity parties.
The AutoMerge plugin always runs synchronously, and Microsoft imposes a hard 2-minute plugin execution limit. Large sets, especially relationship-heavy ones, are far more likely to hit that ceiling.
CRM resources are shared across many Dynamics tenants. The same operation that times out mid-afternoon may complete fine in the evening.
If you've configured complex field preservation via workflow rules, those rules must run synchronously, which slows each merge. That's expected, and a reason to merge in smaller batches.
The main lever: Maximum Duplicate Set Size
Requests in the Management App carry a Maximum Duplicate Set Size, default 20. You can lower it per request.
Step it down gradually (20 → 10 → 5 → 2) rather than jumping straight to the smallest value.
Why stepping down matters
When a genuine duplicate group is larger than the cap, tagging splits it into multiple sets of at most that size.
Say you have a group of 100 actual duplicates and a cap of 20. Tagging produces five sets of 20. AutoMerging all five leaves five winner records still active, one per set, and those five are still duplicates of one another. The next Analyze/Tag pass catches them as a new set and merges them down further.
The number of passes is not fixed at two. If the leftover winners from a round still exceed the size limit, that round splits into multiple sets as well, pushing you to a third pass or more.
That's why stepping down gradually keeps the iteration manageable. A cap of 2 on a large backlog of duplicates produces an enormous number of tiny sets and many rounds of merging.
When even the smallest setting times out
If you've merged down to a handful of large, relationship-heavy sets and they still time out at the smallest cap, switch those specific sets to Dynamics' native (out-of-the-box) merge.
Native merge runs through an asynchronous service rather than our synchronous plugin, so it isn't subject to the 2-minute ceiling.
How to do it
Native merge handles two records at a time, so a larger set is merged stepwise into the same winner, in ascending rank order:
For a 4-record set ranked 1–4:
- Merge Rank 2 into Rank 1
- Merge Rank 3 into Rank 1
- Merge Rank 4 into Rank 1
That ordering is not arbitrary. It's the same ascending-rank sequence AutoMerge follows internally when merging a set of three or more. You're replicating our own process by hand, not improvising a workaround.
On the native merge dialog, tick "Merge records by choosing fields with data" before confirming.
That checkbox is what pulls the losing record's populated fields onto the winner. Without it you lose AutoMerge's field-preservation behavior for that pair, and the loser's data stays stranded on the deactivated record.
Quick reference
| Situation | Do this |
|---|---|
| Timeouts on a full page of sets | Select fewer sets per merge |
| Timeouts persist on small selections | Lower Maximum Duplicate Set Size: 20 → 10 → 5 → 2 |
| A few large, relationship-heavy sets still fail at the minimum | Native merge, stepwise, ascending rank, with the "choose fields with data" box ticked |
| Timeouts only at certain hours | Try again outside peak hours |
Related
- Submitting requests: where the size setting lives
- Clearing a large backlog of duplicates: sequencing the whole project
- Common errors: everything else