How do I find all duplicate contacts in Salesforce without buying a tool?

Two paths depending on your edition. Enterprise/Performance/Unlimited/Developer: Setup → Duplicate Management → Duplicate Jobs. Configure a job with your Matching Rule, run it, review the candidate clusters in the UI, merge or export. Professional/Essentials: no Duplicate Jobs, so fall back to SOQL. Run `SELECT Email, COUNT(Id) FROM Contact WHERE Email != null GROUP BY Email HAVING COUNT(Id) > 1 ORDER BY COUNT(Id) DESC LIMIT 200` to surface the worst offenders, then either merge them three at a time in the Contact view or write a Data Loader job that pulls each cluster's record IDs and merges via the SOAP merge API. Either way, do a sample-of-50 manual review before any bulk action — automated merges sometimes pick the wrong 'master' record and lose data.

Why does my integration keep creating duplicate contacts when I think I have dedup configured?

Three usual culprits: (1) Your Duplicate Rule is set to 'Alert' instead of 'Block' — Alert lets the API silently save the duplicate anyway. Set it to 'Block' and integrations will get a DUPLICATE_DETECTED error they must handle. (2) Your integration isn't using upsert semantics — many connectors default to 'create' which never checks for existing records. In HubSpot, the relevant setting is 'Sync Rule: Update record in [target] if it already exists'. (3) Your Matching Rule is too strict — if you're matching on Email AND FirstName AND LastName all exact, a sync with 'John' vs 'Jon' creates a new record. Loosen one criterion or add a fuzzy fallback.

What's the difference between Matching Rules and Duplicate Rules, and do I need both?

Yes, you need both. They do different things. Matching Rules answer 'are these two records duplicates?' — they define the comparison logic (email exact, name fuzzy, address fuzzy with 90% similarity threshold, etc.). They're pure logic with no action attached. Duplicate Rules answer 'what should we do when a match is found?' — they bind a Matching Rule to an action (Alert, Block, Allow) and a trigger (Create, Edit). A Matching Rule alone is inert; it identifies duplicates but doesn't stop them. A Duplicate Rule with no Matching Rule has nothing to match against. Salesforce ships Standard Matching Rules for Lead, Contact, Account, and Person Account; you can clone and customize them or write your own.

Can I merge duplicate contacts in bulk using only Salesforce native tools?

Yes, via Duplicate Jobs (Enterprise+), but with caveats. Duplicate Jobs finds the duplicates in bulk but the merge step is interactive — you review each cluster and pick the master. There's no 'merge everything matching this rule automatically' button, by design (auto-merge has serious risk of data loss). For true bulk auto-merge, you need either Data Loader + a custom script using the SOAP merge() API, or a third-party tool. The Salesforce UI itself merges 3 at a time. The SOAP merge() API can merge up to 3 records per call (1 master + 2 duplicates) and you can batch many calls in parallel.

Does the Lead-to-Contact conversion process check for existing duplicate Contacts?

Only if explicitly enabled. By default, converting a Lead creates a new Contact regardless of existing records. To enable matching: Setup → Duplicate Management → Duplicate Rules → edit the Contact Duplicate Rule → check 'Use this rule during Lead conversion'. With that enabled, the conversion UI surfaces existing Contact matches and lets the rep merge into them. Note: the matching only fires through the UI, not through the API — if your sales process converts Leads programmatically via Apex or an integration, you have to call `mergeRecords` explicitly.

What's the right master-record policy when merging duplicates programmatically?

Depends on what the duplicates have attached. Common heuristics, in order of safety: (1) Most-recently-active wins (latest LastActivityDate or LastModifiedDate) — safe default for marketing-driven dedup. (2) Most-complete-data wins (count non-null fields, highest count wins) — good when one record is a stub from an integration and the other is the real record. (3) Oldest wins — preserves the longest history; useful if downstream reports group by Contact creation date. (4) Manually picked — for high-value records (large opportunities, major accounts), don't auto-merge. Whatever rule you pick, log the merge decisions so you can audit later and so users can find 'where did Contact X go?' by querying the merge log.

How fast do duplicates accumulate, and what's the cost of waiting six months to fix this?

For a mid-market B2B company without dedup configured, we typically see 50-200 new Contact duplicates per week from integration upserts and Lead conversions. After 6 months that's 1,200-5,000 records. The merge cost grows non-linearly because each duplicate accumulates related records (Activities, Tasks, Opportunity contact roles, Campaign Members) that have to be re-parented during the merge — Salesforce handles most of this automatically, but data-loss edge cases multiply with time. The other compounding cost is reporting: every duplicate Contact counted in a 'unique buyers per quarter' number is a number that's wrong. Cleaning duplicates after they've polluted historical reports requires re-baselining the report, not just merging records.

Fix Guide

How to Fix Duplicate Contacts in Salesforce

Step-by-step fix guide with AI-powered diagnosis from BuildForce.

Duplicate Contacts in Salesforce come from three sources, in order of how much damage they do: integrations creating new records when they fail to match an existing one (HubSpot, Marketo, Pardot are usual suspects), manual imports via Data Loader that bypass the UI's dedup checks, and Lead-to-Contact conversions where the existing Contact isn't surfaced. The native fix is a two-step Salesforce configuration plus an integration-side change: in Setup → Duplicate Management, build a Matching Rule that defines what counts as a duplicate (email exact + optional fuzzy name fallback) and pair it with a Duplicate Rule set to 'Block' (not 'Alert') for the Create action. Then in each integration, set the upsert key to Email or a stable external ID so syncs update instead of insert. For records already in the database, the Duplicate Jobs feature (Enterprise/Unlimited only) generates merge candidates in bulk; for Professional Edition, Data Loader plus a SOQL group-by-email query is the manual fallback.

Matching RulesDuplicate RulesIntegration DedupBulk Merge

Get AI-Powered Diagnosis See Pricing

Duplicate Contacts is the rare problem where the volume tells you the root cause. If you have hundreds of duplicates with mostly-clean email addresses, it's an integration — something is upserting badly at scale. If you have dozens with weird email casing or whitespace differences, it's manual imports. If you have hundreds where one record is from 'Lead Conversion' and the other was a pre-existing Contact, your sales team is converting without searching first.

The damage is compounding. Every duplicate Contact attached to a Marketing Cloud journey sends two emails to the same person. Every duplicate attached to an active Opportunity creates split sales credit. Every duplicate counted in a board-level metric inflates the number. The cost of cleaning them up grows with the square of how long you've waited — merge a 50-record duplicate cluster today and it's a 30-minute job; merge the same cluster after another year of campaign activity and you're untangling 18 months of related activities, tasks, and opportunities.

The most important configuration step isn't the rule itself — it's setting the Duplicate Rule to 'Block' rather than 'Alert'. 'Alert' shows the user a warning and lets them proceed. Through the API (which is what integrations use), 'Alert' is silent and lets the record save anyway. 'Block' actually returns a DUPLICATE_DETECTED error that the integration must handle. Many teams have 'Alert' configured and believe they're protected; they're not.

Duplicate Jobs is available in Enterprise, Performance, Unlimited, and Developer editions; NOT in Professional or Essentials. Professional Edition orgs must rely on Data Loader + SOQL group-by queries for bulk dedup. The Standard Contact Duplicate Rule ships disabled — admin must explicitly enable and configure the Action setting.

Source: Salesforce Help — Duplicate Management Setup, Spring '26

Symptoms

Same customer appears multiple times with different contact records

Email notifications going to the same person twice after campaigns

Sales reps seeing multiple 'same company' accounts with split contact lists

Integration sync creating new records instead of updating existing ones

Reports showing inflated contact counts that don't match expected numbers

Root Causes

Duplicate Rules not configured or set to 'Allow' instead of 'Block'

Salesforce ships with Duplicate Rules in 'Alert' or disabled mode. Unless set to 'Block', users can create duplicates with just a warning. Integration APIs bypass UI warnings entirely.

Integration upsert keys not set

Integrations like HubSpot and Marketo create new records when they can't match an existing one. Without a configured external ID field or email-based match key, every sync creates new records.

Mismatched email formats

Matching on email fails when the same address appears as 'John@Company.com' and 'john@company.com', or when email aliases and forwarding addresses are used inconsistently.

Lead-to-contact conversion without deduplication

Converting Leads to Contacts without checking for existing Contact records creates duplicates. Salesforce doesn't automatically merge the Lead's activity with an existing Contact.

How to Fix It — Step by Step

Audit existing duplicates

Run Salesforce's built-in Duplicate Jobs (Setup → Duplicate Management → Duplicate Jobs) to get a count of matching records. This is available in Enterprise and Unlimited editions.

Example

SELECT Email, FirstName, LastName, COUNT(Id) cnt FROM Contact GROUP BY Email, FirstName, LastName HAVING COUNT(Id) > 1 ORDER BY cnt DESC LIMIT 50

Configure Matching Rules

In Setup → Duplicate Management → Matching Rules, create or enable rules for Contact matching. Use 'Email Exact' as the primary match criterion, with 'Name Fuzzy' as a secondary criterion for cases where email is blank.

Set Duplicate Rules to 'Block'

In Setup → Duplicate Management → Duplicate Rules, edit the Standard Contact Duplicate Rule. Change the Action from 'Allow' to 'Block' for the Create action. This prevents duplicates through the UI.

Configure integration upsert keys

In each integration platform (HubSpot, Marketo, etc.), set the upsert key to Email for Contact syncs. This tells the integration to update existing records instead of creating new ones.

Bulk merge existing duplicates

Use Salesforce's Duplicate Jobs to merge existing duplicates in bulk. Review the merge candidates, set the 'master' record policy (most recent activity, or most complete data), and run the merge job.

Monitor with BuildForce duplicate detection

Enable BuildForce's duplicate detection check to receive weekly reports on new duplicate records entering your org, with the source integration identified.

Real-world incidents we've seen

An e-commerce company whose Marketo→Salesforce sync had matched on Email but treated 'john@company.com' and 'John@Company.com' as different records. 14,000 duplicates accumulated over 8 months before someone noticed campaign sends were doubling. Fix: normalize emails to lowercase before the upsert, then merge the existing 14k duplicates with a master-record policy of 'most recent LastModifiedDate wins'.
A B2B sales org where Lead-to-Contact conversion was happening without the rep checking for existing Contacts first — Convert button was being clicked from list views without opening the record. ~600 duplicate Contacts created over 3 months. Fixed structurally by turning on 'Use Matching Rules' in the conversion flow and adding a required 'Check for Duplicates' step.
A nonprofit that ran a 60,000-record Data Loader import to backfill historical donors. The CSV had been deduped against the wrong export of the org. Result: 18,000 new duplicate Contacts on top of existing records. Recovery took three weeks because the merge process had to preserve the donor history attached to BOTH records — automated bulk merge couldn't handle the activity-attribution logic.