How Salesforce duplicate records arise, and what merging them changes
The entry points by which Salesforce duplicate records bypass the duplicate rules, the limits of native tooling, and the dependencies that make a merge consequential.
Duplicate records are not primarily a discipline problem. They are a structural consequence of how records enter Salesforce. Native duplicate and matching rules do not run at all for some entry points: Quick Create, Undelete, Lightning Sync, Einstein Activity Capture and lead conversion without the Apex conversion path. Where they do run, records saved together are compared only with records already in Salesforce, not with one another, and an integration can be configured to save records that rules set to alert would otherwise stop. Every integration, web form and enrichment tool is therefore a possible entrance for duplicates, and the objects most exposed are precisely the ones an agent reads first: Lead, Contact and Account.
The limits of Salesforce deduplication tools
Native tooling is further bounded by design. An object supports at most five active duplicate rules with three matching rules each; merges are performed three records at a time; there is no scheduled or mass merge; and custom-object support is limited. Salesforce sets out these rules in its guide to duplicate management. For many organizations of the size that invests in agentic AI, the volume of duplicates exceeds what these tools can practically address, and a purpose-built deduplication tool or a programmatic approach in a migration database becomes necessary. Our data experts use fuzzy-matching methods similar to those of the dedicated vendors, such as Levenshtein distance on normalized names and domains, and recommend those vendors where the client will operate the tool after handoff.
What merging Salesforce duplicate records changes
A merge changes record identity, ownership and relationships. Any Flow, trigger, routing rule, integration mapping, report filter, territory assignment or external system that holds the losing record's identifier will, after the merge, reference a record that no longer exists. Salesforce's merge moves the losing record's related records to the surviving record; a merge performed outside it, as in a migration database, must re-parent them itself. Roll-up fields recalculate, and integrations that key on the Salesforce ID must be reconciled. This is why our consultants inventory, during the assessment, the automation and integrations dependent upon each in-scope object before any merge is designed, and why merge decisions on Accounts in particular are treated as a cross-functional matter with every team that relies on the account, from sales and service to billing and revenue.
Assess the data before the agents depend upon it
The first call is with the practitioners who would do the work, not a sales intermediary. The measures come first and the estimate follows.