A few years back we were brought in to assess a Salesforce org for a mid-size telecom company. Their sales team had been complaining for months that the CRM was unreliable — account managers were calling the same prospect twice, lead routing was assigning records to multiple reps, and nobody trusted the data. When we dug into the org, Duplicate Rules were technically turned on. But the Matching Rules feeding them were the stock standard configuration, completely untuned for how this company actually named accounts. "a Vietnamese telecom client" and "an enterprise client Telecommunications" were living as two separate Account records. Nobody had touched the fuzzy matching thresholds, and because the Duplicate Rule was set to Alert instead of Block, sales reps had been clicking past the warnings for so long they stopped seeing them.
That situation — half-configured duplicate management that creates noise without enforcing anything — is the most common thing we see when inheriting an org. So let us walk through how the system actually works, where it breaks down, and how we approach the configuration on every project we deliver.
Matching Rules and Duplicate Rules Are Not the Same Thing
We have to be explicit about this because the terms get conflated constantly. A Matching Rule answers one question: are these two records the same? It specifies which fields to compare and whether that comparison is exact or fuzzy. A Duplicate Rule answers a different question: given that these two records matched, what should happen next? It references the Matching Rule and defines the enforcement action — alert the user, block the save, or silently log it.
Without both configured and active, nothing works. We have seen orgs where a well-crafted Matching Rule existed but the Duplicate Rule referencing it was inactive, so the system detected nothing. We have also seen orgs where a Duplicate Rule was active but referencing a Matching Rule that had been deactivated — same result. The two components have to be alive and connected for detection to actually fire.
How Matching Rules Work in Practice
Salesforce ships three Standard Matching Rules out of the box: one for Contacts, one for Leads, and one for Accounts. They cover the basics — first name, last name, email, phone, company name, billing address, website — and apply a mix of exact and fuzzy matching depending on the field. Email addresses are compared exactly because the structure of an email address is specific enough to be reliable. Name fields use fuzzy matching because humans are inconsistent: "Bob" and "Robert" should probably resolve to the same person, and "Nguyen Van An" with a middle name dropped should still match.
The fuzzy matching on company names is where we spend most of our configuration time. The standard threshold handles obvious cases like "Inc." versus "Incorporated," but it will miss more subtle variations — abbreviations specific to the Vietnamese market, romanization differences in company names, subsidiaries sharing a parent brand. For any object beyond the standard three, you will need to build a custom Matching Rule from scratch, which is also the right moment to get precise about which fields actually define uniqueness for that object. In a healthcare context, a patient record number might be the only field that matters and it should be compared exactly. In a B2B sales context, the combination of company name and domain is usually a stronger signal than either alone.
Configuring Duplicate Rules: Alert Before You Block
Once the Matching Rule is in place, the Duplicate Rule wraps around it and defines the user experience. The three options are Allow (the record saves, a warning appears in a related list), Block (the save is prevented until the user resolves the duplicate), and Report (the match is logged silently without surfacing anything to the user). We almost never recommend going straight to Block on a freshly configured rule.
Here is why: a Matching Rule that has not been tuned against real data will produce false positives, and a Block action on a false positive is a hard stop for a sales rep trying to create a legitimate record. The first time that happens on a new org, trust in the system evaporates. Our standard approach is to activate with Alert first, let the Duplicate Record Sets accumulate for a few weeks, then review the false positive rate before deciding whether to tighten the match criteria or flip the action to Block. Accounts and Contacts — where duplicate records cause the most downstream harm in reporting and territory management — are where we eventually land on Block. For Leads, where the volume is higher and the stakes are lower, we often stay on Alert indefinitely and handle cleanup through a weekly data steward review.
The Duplicate Rule also controls whether detection fires on API-created records, which is a detail that matters enormously in integration-heavy orgs. We always enable API detection because the dirtiest data usually comes in through integrations, not manual entry.
Cross-Object Detection: The Lead-to-Contact Gap
One configuration that gets skipped surprisingly often is cross-object duplicate detection. By default, when a sales rep creates a new Lead, Salesforce checks it against other Leads. It does not check it against existing Contacts unless you explicitly set up a Duplicate Rule to do so.
The practical consequence: a person who is already a Contact in your org — maybe a customer from a previous deal cycle — gets submitted as a new Lead through a web form, lands in the queue, and gets worked by an outbound rep who has no idea this person is already a customer. We saw this happen at a a Vietnamese conglomerate client where their website was feeding Leads directly into Salesforce and no cross-object rule was configured. The sales team was cold-calling existing enterprise clients.
Fixing it requires a Duplicate Rule on the Lead object with the matching object set to Contact. The rule fires on Lead creation, runs the Contact Matching Rule criteria against the incoming Lead's fields, and alerts (or blocks) if a match is found. It is a separate rule from the Lead-to-Lead duplicate check — both should be active.
When a Record Becomes a Duplicate After the Fact
Something that catches admins off guard: Duplicate Rules apply on both insert and update, which means a record that was perfectly clean when it was created can get flagged later. If you onboard a new customer as an Account and three months later a second rep creates a nearly identical Account for the same company, the older record now has a potential duplicate — and if your Duplicate Rule fires on update, editing either record will surface the warning.
This is actually the intended behavior, and Duplicate Record Sets are how you track it. The Sets act as a junction object linking the matched records together, and they persist until a data steward reviews them and either merges the records or dismisses the alert. For orgs with a serious backlog of historical duplicates, reviewing the Sets is the starting point for any cleanup effort — it tells you which records are already flagged and how severe the overlap is.
Merging: Native Functionality and Its Limits
Salesforce provides native merge for Accounts, Contacts, and Leads — three records at a time, one object type per operation. The merge designates a winning record, migrates all related records and activities from the losers to the winner, and deletes the losing records. It is a manual process: a user or admin has to review the candidates and initiate the merge. For small-scale cleanup or for a data steward handling the weekly Duplicate Record Sets queue, native merge is perfectly adequate.
For orgs with thousands of duplicates that accumulated before Duplicate Rules were activated, native merge alone is not realistic. We have used Dedupe Solutions from AppExchange on a few larger projects to automate the matching-and-merging logic at volume. The important thing is to get the native rules calibrated first — AppExchange tools work better when the match criteria are already well-defined, and running automated merges without validated criteria is how you destroy data that should not have been merged.
How We Approach This on Every Project
Our standard checklist when configuring duplicate management on a new org: activate Matching Rules and review the fuzzy matching thresholds against actual data samples before doing anything else; build the Duplicate Rules with Alert first on all objects; add a cross-object Lead-to-Contact rule immediately; and schedule a review of the Duplicate Record Sets after four weeks to assess false positive rate before tightening enforcement. For any custom objects where uniqueness matters — partner records, vendor entries, patient records — we build custom Matching Rules tailored to the fields that actually define uniqueness for that entity.
The system Salesforce ships is capable enough to handle most scenarios without AppExchange. But it only works if both layers are configured, active, and tuned together. A Duplicate Rule pointing at an untuned Matching Rule is how you end up with a system that either blocks legitimate work or lets everything through unchallenged — and either failure mode erodes trust in the CRM faster than having no duplicate management at all.
