AutoMerge versus Native/OOB Merge
Dynamics 365 has duplicate detection and a merge dialog built in but they weren't designed for volume or for messy real-world data. Below is the comparison, capability by capability.
Verified against Microsoft's current duplicate detection and merge documentation, August 2026.
Matching duplicates
Native matching covers the basics: whole-string matches, partial ZIP matches, and criteria based on fields on the record itself, across a limited number of rule sets.
| Capability | Native CRM | AutoMerge |
|---|---|---|
| Number of match rules allowed | Limited to 5 published rules per table | Unlimited |
| Match on related-record fields (e.g. parent account's phone) | No | Yes |
| Alternate spellings, misspellings, phonetic matching | No | Yes |
| Nickname matching ("Bob" = "Robert") | No | Yes |
| Phone punctuation ignored across formats | No | Yes |
| Company name variants ("The Acme Company" = "Acme") | No | Yes |
| Street, state, and country address variants | No | Yes |
| Cross-field matching (e.g. email1 matches email3) | No | Yes |
| Match precision score per duplicate set | No | Yes |
| Detection partitioning (e.g. by business unit) | No | Yes |
| Match Leads to existing Accounts/Contacts | No | Yes |
The practical consequence of the first row: five published rules per table is a real ceiling. Most organizations need more than five ways of recognizing that two records are the same person.
Merging duplicates
Native CRM has a manual merge dialog for picking a winner and merging one set of two records at a time. It works. It isn't built for thousands of sets.
| Capability | Native CRM | AutoMerge |
|---|---|---|
| Manual merge dialog | Yes (2 records) | Yes 2 |
| Duplicate sets merged per operation | One set of two records | Multiple sets of two or more records each, in one click |
| Automatically merge all duplicate sets | No | Yes |
| Match precision score per set | No | Yes |
| Preserve populated fields otherwise lost on the loser | No | Yes |
| Address block preservation (kept together, not mixed) | No | Yes |
| Winner determined from the record's own fields | Yes | Yes |
| Winner determined from related-record fields (owning user, parent account, business unit, primary contact) | No | Yes |
| Quickly validate or change which record wins | No | Yes |
| Exclude records from future analysis | No | Yes |
| View historically merged loser records from the winner | No | Yes |
| Dashboards of historical and upcoming merges | No | Yes |
| Configure merges to run outside business hours | No | Yes |
2. The Potential Duplicates Grid (web resource) can be configured onto any CRM form of your choosing, and lets you view and merge 2 or more records at once. See Potential Duplicates subgrid.
The field-loss problem worth knowing about
Certain columns never appear in the native merge dialog at all: hidden columns, parentaccountid and parentcustomerid, Owner-type columns, and some Choice columns.
Because they aren't shown, their values on the losing record can't be selected, so they're silently lost. Nobody chose to discard them; the dialog simply never offered them.
AutoMerge preserves any populated field regardless of whether the native dialog would have displayed it.
When native merge is the right tool
It genuinely is, in one case: a handful of very large, relationship-heavy sets that time out even at the smallest Maximum Duplicate Set Size. Native merge runs asynchronously and escapes Microsoft's 2-minute synchronous plugin limit.
See Timeout errors for how to do that correctly, including the checkbox that preserves field data.