How to Find Duplicates Across Entities in Dynamics 365

If you manage data in Dynamics 365, you've likely seen this: a lead comes in from your website, and it turns out to already exist as a contact. Now there are two records for the same person, and neither one has the full picture.

Dynamics 365 ships with native tools for catching duplicates across entities. Configuring them well, and knowing where they stop, is the harder part. This guide walks through building a cross-entity rule, running bulk detection jobs, and the points where the native tools need help.

Why cross-entity duplicates cause real problems

A duplicate record isn't just clutter. When your sales team reaches out to the same person from two different records, you look uncoordinated. When marketing sends the same email twice, unsubscribe rates climb. When a report counts the same person twice, the numbers behind a decision are wrong.

It also affects any AI feature built on top of that data, lead scoring or opportunity insights included. A lead split across two records gives the model half a history to work from, so the score or insight comes back wrong, with a confidence number attached that makes it look more certain than it is.

Cross-entity duplicates are harder to catch than same-entity ones. Two Account records for the same company under slightly different names sit in one table, so a single detection rule can compare them directly. A Lead that actually represents an existing Contact or Account lives in a different table entirely. Because duplicate rules are usually configured per entity, each one is checked in isolation, so a Lead can pass validation even when a matching Contact already exists.

The fix starts with understanding how Dynamics 365's duplicate detection rules work today, and where they stop, so you can design rules that catch both same-entity and cross-entity matches.

Base Record Type vs. Matching Record Type

Dynamics 365 duplicate detection rules rely on two settings: Base Record Type and Matching Record Type.

Base Record Type is the entity you're checking. Matching Record Type is the entity you're comparing it against. To catch new leads that match existing contacts, set Base Record Type to Lead and Matching Record Type to Contact. That tells the system: when someone creates or updates a Lead, check whether a Contact with the same information already exists.

You can flip it too. Base Record Type Contact, Matching Record Type Lead, checks new contacts against existing leads. Most organizations need both rules: one to catch leads that match contacts, one to catch contacts that match leads.

Setting up a cross-entity duplicate detection rule

Here's how to configure a rule that compares two different entities, using a Lead-to-Contact email match as the example.

1. Open duplicate detection rules

Go to your Dynamics 365 Sales (or other model-driven) app. Open Advanced Settings, then go to Settings > Data Management > Duplicate Detection Rules. In some environments this sits under the classic settings area instead, at the same path.

2. Create a new rule

Click New and name the rule something specific, like "Lead to Contact - Email Match."

3. Set Base and Matching Record Types

Set Base Record Type to the entity you want to check, Lead in this example. Set Matching Record Type to the entity you want to compare against, Contact. The Rule Criteria area below is where you define which fields from each entity get compared.

4. Define the matching criteria

For a Lead-to-Contact email match:

• Base Record Field: the Lead's primary email field (Email).
• Matching Record Field: the Contact's primary email field (Email or Email Address 1).
• Operator: Exact Match.

You can add multiple criteria lines. Within one rule, they're combined with AND: every condition must be true for a record to count as a duplicate. For OR-type behavior, you need separate rules, one per pattern.

5. Configure additional settings

Three settings are worth knowing:

• Exclude inactive matching records, if you only want to check against active records in the matching entity.
• Case sensitive, if [email protected] and [email protected] should count as different values.
• Ignore blank values, so empty fields don't get flagged as matches.

6. Save and publish

Click Save and Close, then select the new rule and click Publish. A rule that isn't published doesn't run. Publishing generates the internal matchcodes Dynamics 365 uses to compare existing records, which can take noticeable time in larger environments.

Handling custom tables

Custom tables work the same way as standard entities, with one extra step first: open Power Apps, go to the custom table, click Edit table properties, and under Advanced options check Duplicate detection. Once that's on, you create rules for the custom table exactly as you would for Contacts or Leads. Within-entity and standard rule-based matching both work.

When duplicate detection actually runs

Dynamics 365 doesn't check for duplicates in every scenario.

It runs during manual record creation or updates in the UI, Outlook offline-to-online sync, and data imports if duplicate detection is enabled in the import settings.

It does not run during lead conversions, record merges, status changes like activating or deactivating a record, or API calls, unless SuppressDuplicateDetection is explicitly set to false.

That last one matters most. If you're creating records through Power Automate, an integration, or custom code, duplicate detection is off by default. You have to enable it explicitly in the API call, and even then the native system only blocks or logs based on your rule configuration. It doesn't alert a user, because there's no user in the loop to alert.

Scheduling bulk duplicate detection jobs

Real-time detection only catches new or updated records. For duplicates already sitting in your system, use a scheduled detection job instead.

Go to Settings > Data Management > Duplicate Detection Jobs, click New, and the wizard walks you through selecting which entities to scan, which published rules to apply, a recurrence (daily, weekly, or monthly), and whether to email a notification when the job completes.

Scheduled jobs matter most right after a data import or migration, when duplicates arrive through a channel that bypasses real-time detection entirely.

The native limits you'll run into

Dynamics 365's native duplicate detection works well for straightforward scenarios, but it has real constraints.

Five published rules per entity. Hit the limit and you have to unpublish or delete an existing rule before adding another.

No fuzzy matching across entities. Phonetic matching is available within a single entity, but cross-entity rules don't support it. Matching is exact, or based on the first or last N characters.

Matchcode length limits. Each rule builds a matchcode from the fields you select. Add too many criteria and you exceed the matchcode length, and detection can then fail silently, with no error to tell you why.

No native cross-object merge. Dynamics 365 can tell you a Lead matches a Contact, but it won't merge them. That step is manual, or needs custom automation.

Performance at scale. Large datasets slow detection jobs down and can create a backlog, especially with several rules running at once.

A worked example: Lead vs. Contact

Marketing runs a campaign and imports 1,000 leads. Some of those leads are already contacts in the system.

To catch that, create a rule with Base Record Type Lead, Matching Record Type Contact, and criteria Email (exact match) AND Last Name (exact match). Publish it. Now when a lead is created with the email [email protected] and last name Smith, the system checks whether a contact with that email and name already exists, and the user sees a duplicate warning before saving.

Run a bulk detection job on the same rule to scan existing leads and catch matches that were already sitting in the system before the rule existed.

Viewing and managing detected duplicates

For real-time detection, a user sees a duplicate warning dialog at the point of saving and can choose to save anyway or go review the existing record.

For scheduled jobs, go to Settings > Data Management > Duplicate Detection Jobs, open the completed job, and click View Duplicates to see every match found. From there you can merge records manually or export the list for review.

Dynamics 365 doesn't auto-merge. Every merge needs a decision about which record to keep and which field values to preserve. That's by design, and it means duplicate management stays a manual process unless you build automation around it.

Signs you've outgrown native detection

A few signals that the native tools have hit their ceiling:

• You're hitting the five-rule-per-entity limit.
• You need flexible matching on names, addresses, or company names.
• You want duplicate Leads converted into existing Contacts or Accounts automatically.
• Detection jobs are taking too long or timing out.
• Records arriving through an API are creating duplicates the native system never catches.

How Plauti extends cross-entity detection

Plauti runs natively on the Dynamics 365 platform, so no data leaves your environment. Here's what it adds on top of the native rules, spanning the Clean and Prevent stages of managing CRM data.

Cross-entity search for leads. When a Lead is created or updated, Plauti checks whether that person already exists as a Contact or Account and notifies the user before they save if a match is found. The same cross-entity check can run as a scheduled batch job across your existing data, surfacing overlaps between Leads, Contacts, and Accounts you already have.

Broader matching methods. Beyond exact field matching, Plauti includes company name matching that handles variants like "Acme Corp" vs. "Acme Corporation." Wider fuzzy matching is in active development for upcoming releases.

As-you-type notifications. Plauti can flag a likely duplicate while a user is still typing, not only when they save, so the warning shows up before the form is even finished.

API insert detection. Records created through an API are automatically checked against your configured scenarios, with matches flagged and queued for review, no extra setup needed per API call. This closes one of the more common gaps in native detection.

Lead conversion, not just a flag. When Plauti finds a Lead that matches an existing Contact or Account, you can convert that Lead directly into the matching record, in real time or in a batch job, rather than just getting told the two might be the same person.

Merge rules you set. For within-entity duplicates, a guided merge screen lets you choose, field by field, which value wins: most recent update, a specific source system, or a fixed master record. Auto-merge handles the straightforward cases without a person in the loop.

Jobs that run outside Dynamics 365. Batch jobs process in a separate environment or on your own server, so neither option adds load to Dynamics 365 while a job runs. Results come back once processing finishes.

A full audit log. Every merge, conversion, deactivation, and deletion is recorded, along with who did it and when. That's the kind of traceability that's hard to reconstruct after the fact if you need it for compliance or governance.

Custom entities included. Detection, prevention, and batch jobs all work on any entity, custom tables included. You choose which entities are active and which rules apply to each.

Practices that hold up at scale

A few habits worth building in from the start.

Start with high-confidence matches. Use exact email matching before layering in name matching, so you're not chasing false positives while you're still building confidence in a rule.

Document your rules. Keep a record of which rules are active, what they match on, and why. It saves time when troubleshooting or onboarding a new admin.

Test before publishing. Build the rule in a sandbox first, run a detection job, and check the results for false positives before it goes live.

Schedule jobs for off-hours. Detection jobs can affect system performance, so run them overnight or on weekends when fewer people are working in the system.

Monitor job performance. Check the detection job history regularly. If jobs are failing or running long, simplify the criteria or split the rule.

Set expectations with your users. Make sure your team understands what a duplicate warning means and how to respond to it. A warning that gets ignored isn't doing anything.

Plan for API inserts separately. If records arrive through integrations, marketing platforms, or imports, those channels need their own duplicate strategy. Native detection doesn't cover them by default.

Next steps for cross-entity detection

Finding duplicates across entities in Dynamics 365 is doable with native rules, but it takes deliberate configuration and a clear sense of where the system stops.

Set up cross-entity rules with the right Base and Matching Record Types, define clear matching criteria, and schedule regular detection jobs, and you'll catch most duplicates before they cause a problem. When the volume, the matching complexity, or the API traffic outgrows what native rules can do, that's the point where Plauti picks up: cross-entity prevention, Lead conversion, and jobs that don't add load to your environment.

Clean data isn't an accident. It comes from rules someone maintains and a process the team actually follows.