Dynamics 365 ships with duplicate detection rules turned on for accounts, contacts and leads, and that is roughly the last bit of attention most projects ever give them. I have lost count of the environments I have gone into where the matching rules are still sitting on their out of the box defaults years after go live, quietly failing to catch the exact duplicates the sales team keeps creating.
That matters more than it sounds like it should. Bad duplicate detection does not cause a dramatic failure. It causes a slow, compounding mess: the same contact created three times under slightly different spellings, a lead converted into an account that already exists, a report that double counts revenue because two records are really the same customer. None of it looks urgent until someone tries to actually trust the data for something important.
How Matching Rules Actually Work
A duplicate detection rule in Dynamics 365 is built from a base entity, a matching entity, and a set of criteria fields, each with its own matching method. Exact match compares fields as they are stored. Same first characters lets you match on a prefix, useful for things like account numbers or reference codes. Same first characters combined with case insensitivity and a bit of trimming handles the messiness of real data entry far better than exact match on its own.
The Default Rules Are Not Enough
The rules Microsoft ships out of the box are a reasonable starting point and nothing more. They typically match contacts on email address and accounts on account name, which sounds sensible until you remember how many ways a company name gets typed. Rob Heeley Consulting, R Heeley Consulting Ltd and Rob Heeley Consulting Limited are three completely different strings to an exact name match, and every one of them sails straight past the default rule.
The fix is not complicated, it just needs someone to actually do it. Add a second matching field like phone number or postcode alongside account name, so a rule only needs one strong signal to catch a match rather than relying on the name being typed identically. For contacts, matching on email is good, but adding a rule that also checks first name plus last name plus parent account catches duplicates created before an email address was even known.
Real Time Versus Bulk Detection
Dynamics 365 gives you two separate places to apply these rules, and most teams only ever think about one of them. Real time detection runs the moment a user tries to save a record, and it is what stops a salesperson creating a contact that already exists. Bulk detection runs on demand or on a schedule across records that already exist, which is what you actually need to clean up a database that has been quietly accumulating duplicates for years.
Turning on real time detection without ever running a bulk job is the single most common gap I see. It stops the problem getting worse from today, but it does nothing about the thousands of duplicate contacts already sitting in the system from before anyone was paying attention. Run a bulk detection job, review the results properly rather than merging blindly, and you will usually be surprised how much of it there is.
Where This Bites You Hardest On Data Migration
This gets particularly painful during a data migration, because you are typically importing records from an old system that had no duplicate detection at all, or a different set of rules to whatever you are building in Dynamics. I cover the wider migration process properly in my guide to Dynamics 365 data migration, but the short version here is to run your duplicate detection rules against a full copy of the migrated data before go live, not after, while it is still cheap to fix.
A Rule Of Thumb I Actually Use
Every matching rule needs at least one field that is genuinely reliable and rarely mistyped. Email address, VAT number, company registration number, a customer reference from another system, anything that is not free text a human types slightly differently every time. Build rules around those fields first, then layer name based matching on top as a secondary check rather than the only check. A rule that only matches on name will always let through more duplicates than one built on a proper identifier, and this is exactly the kind of decision worth pinning down alongside your wider security roles setup while the environment is still young.
My Honest Take
Duplicate detection rules are one of those Dynamics 365 features that everyone assumes is handled because it is switched on by default, and almost nobody actually configures for their own data. It takes half a day of proper attention, reviewing what your specific duplicates actually look like and building rules around your specific fields, and it saves months of downstream reporting problems and awkward conversations about which customer record is the real one.
If your Dynamics 365 environment has never had a proper look at its duplicate detection setup, or you are heading into a migration and want the data clean before it lands, this is exactly the kind of unglamorous groundwork I help clients get right through my Dynamics 365 consulting work.
