Salesforce ships matching rules, duplicate rules and a merge tool. Together they stop a user creating an obvious duplicate at the point of entry. What they do not do is find the duplicates already in the org, match the same person across different name forms, or understand that two records belong to one household or one client entity. That work is manual, and it recurs.
How the native tooling works
This is genuinely useful and most orgs under-use it. Turn it on before you do anything else.
- Matching rules define what counts as the same record: exact or fuzzy comparison across chosen fields.
- Duplicate rules decide what happens when a match is found on create or edit: allow, alert, or block, with a report on the outcome.
- Duplicate jobs (on some editions) scan existing records against your matching rules and produce duplicate record sets.
- Merge combines two or three records, with you choosing the surviving value per field.
The four cases it misses
- Name variance. Bob and Robert, maiden names, hyphenated names, and law firm entities that appear as three different legal names in three different systems.
- Household and entity logic. Two contacts with different surnames and the same address are often one household. Two accounts with similar names are sometimes one client and sometimes a parent and a subsidiary. No matching rule decides that correctly on its own.
- Cross-object duplication. The same person as a lead, a contact and a person account. Matching rules operate within an object.
- Duplicates created by integrations. Every inbound feed that lacks a stable external ID quietly re-creates records, and it does so faster than anyone dedupes.
What merging costs
Merging is not lossless. The losing record's field values are discarded unless you pick them, and while related records generally move to the survivor, anything that depended on the old record ID may not. In a regulated firm the discarded values may themselves be records you were required to retain.
The safe pattern is to capture what you are about to discard, merge, then verify the survivor rather than assume. That is exactly the kind of careful, mechanical work that gets skipped when someone is merging fifty records before a report deadline.
Why it is recurring, not a project
Firms treat deduplication as a clean-up before a migration or a board report. Then the feeds keep running and the forms keep accepting free text, and six months later the org is dirty again. Anything that fixes duplicates once and then stops is not a fix; it is a delay.
Where Caddi fits
Caddi runs the deduplication pass on a schedule rather than before a deadline. It matches records the way your team does, including the judgement calls about households and entities, captures the values it is about to discard, merges, and reports what it changed so the pass is auditable. The rules stay yours; what changes is that nobody has to spend Friday on it.
Related: CRM data hygiene, Mass updating records, and CRM migration.
The recurring half
See deduplication run on a schedule
Caddi matches, merges and reports, using your firm's rules for households and entities.
Frequently asked questions
Does Salesforce have built-in duplicate management?
Yes. Matching rules define what counts as a duplicate, duplicate rules decide whether to alert or block at the point of entry, and duplicate jobs scan existing records on supported editions. Merge then combines records field by field.
Why do duplicates keep coming back?
Because the sources that create them keep running. Integrations without stable external IDs re-create records, web forms accept free text, and staff create a contact rather than searching. Deduplication is therefore a recurring process, not a one-time cleanup.
Is merging records in Salesforce safe?
It is safe for the survivor and lossy for the loser. Field values you do not select are discarded, and anything that depended on the old record ID may not follow. Capture the losing values before you merge, particularly where retention rules apply.
How do you dedupe households rather than contacts?
You need a rule for what a household is, applied above the contact level: shared address plus relationship, or a household key derived from account grouping. Native matching rules work within an object and on field similarity, so household logic has to be expressed somewhere else.