More enrichment data flowing into Salesforce means more chances to create duplicate records. We've watched teams turn on waterfall enrichment, celebrate the coverage numbers, and then spend the next two weeks cleaning up the mess it made in their CRM.
The enrichment worked. The CRM hygiene didn't.
The duplicate problem nobody warns you about
Here's the scenario. Your SDR finds a prospect on LinkedIn. They enrich the profile. ShareCo (or Apollo, or whatever tool you use) finds an email and phone number and pushes it to Salesforce as a new lead.
Except that person already exists in Salesforce. Maybe they came in through a marketing form six months ago. Maybe another rep added them manually last quarter. Maybe they were imported in a CSV during a territory realignment.
Now you have two records for the same person. Different emails, different phone numbers, different activity histories. Your SDR doesn't see the previous conversations. Your marketing team counts them as two separate leads. Your pipeline reports are inflated.
This gets worse fast. If three reps enrich the same person on different days, you get three records. Each one enriched slightly differently because the waterfall hit different providers each time. No single record has the full picture.
What Salesforce gives you out of the box
Salesforce has native duplicate management. It ships with standard matching rules for Accounts, Contacts, and Leads. Most teams either don't know these exist or never activate them.
The system works in two layers: matching rules and duplicate rules. Matching rules define what counts as a duplicate. Duplicate rules define what happens when one is detected.
Matching rules
A matching rule tells Salesforce which fields to compare and how to compare them. You can use exact matching (the values must be identical) or fuzzy matching (approximate matches count).
Salesforce ships with standard matching rules for Accounts, Contacts, and Leads. The standard Contact matching rule, for example, checks first name, last name, email, and mailing street using a combination of exact and fuzzy logic.
The distinction between exact and fuzzy matters more than most admins realize. An exact match on email means john@acme.com only matches john@acme.com. A fuzzy match on email means john@acme.com might match j.smith@acme.com if the fuzzy algorithm scores it close enough. For email addresses, you almost always want exact matching. For company names, fuzzy is usually better because "Acme" and "Acme Corporation" and "Acme Corp" should all resolve to the same account.
You can also create custom matching rules. Salesforce lets you add up to five active duplicate rules per object, each of which can reference a matching rule. If you need to match on a custom field (like a LinkedIn URL or an external ID from your enrichment tool), you'll need a custom rule for that.
Duplicate rules
Matching rules alone don't do anything. They just define the criteria. Duplicate rules use those matching rules to take action when a record is created or edited.
A duplicate rule has two possible outcomes: alert or block.
Alert shows the user a warning that says "hey, this might be a duplicate." The user can read the warning and save the record anyway. This is the default behavior on the standard rules, and it's where most teams get burned. Your SDR sees the warning, clicks past it because they're moving fast, and the duplicate gets created.
Block prevents the record from being saved entirely. The user cannot override it. The duplicate does not enter the system.
Most teams start with alerts because blocking feels aggressive. That instinct is wrong for enrichment workflows. When data is flowing in automatically from an enrichment tool, nobody is reading the alert. The record gets created. The duplicate persists.
Why the standard rules aren't enough for enrichment teams
The standard matching rules Salesforce provides are a starting point. For teams running enrichment at any volume, they fall short in a few specific ways.
The standard rules don't check LinkedIn URLs. If your enrichment tool pushes data to Salesforce with a LinkedIn profile URL, and the same person already exists in your CRM under a slightly different name or email, the standard rules won't catch it. A matching rule on LinkedIn URL would catch duplicates that name and email matching miss, especially for contacts who changed jobs (new company email, same LinkedIn profile).
Fuzzy matching creates false positives on common names. If you have two different John Smiths at two different companies, a fuzzy match on name alone might flag them as duplicates when they aren't. This is why email should be part of every matching rule for Contacts and Leads. Email is the strongest unique identifier for a person in a B2B context.
The 5-rule-per-object limit constrains complex setups. Salesforce caps you at 5 active duplicate rules per object. If you're matching on email, name, phone, LinkedIn URL, and an external enrichment ID, you're already at the limit. Prioritize the rules that catch the most duplicates. In our experience, email exact match and LinkedIn URL exact match catch the vast majority of enrichment-sourced duplicates.
When to block vs. when to alert
This is the decision most teams get wrong.
Block when: The record is being created automatically (API inserts from enrichment tools, CSV imports, web-to-lead forms). No human is evaluating the warning, so an alert is functionally useless. If your enrichment tool pushes data via API, set the duplicate rule to block. The enrichment tool will get an error response, and the duplicate won't enter your CRM.
Alert when: A human is manually creating or editing a record and you want them to check for duplicates before saving. Sales reps creating leads from trade show conversations, for example. The alert is useful here because the rep can see the existing record and decide whether to update it or create a new one.
The middle ground: Some teams use a hybrid approach. Block on Leads (where duplicates are most common) and alert on Contacts and Accounts (where false positives are more costly because merging is destructive). This isn't perfect, but it catches the highest-volume problem without blocking legitimate record creation.
The merge trap: what happens when you merge enriched records
This is the part the LinkedIn post mentioned, and it deserves a full explanation because it catches people off guard.
When you merge two Salesforce records, you pick one as the "master." Salesforce shows you a side-by-side comparison of the two records and lets you choose which field values to keep for each field. Related records (activities, opportunities, campaign history) transfer to the master automatically.
Here's the problem: the non-master record gets deleted. Any field value you didn't explicitly select during the merge is gone. The deleted record goes to the Recycle Bin for 15 days, then it's permanently deleted.
For enriched records, this creates a specific headache. Say you have two Contact records for the same person:
Record A was created six months ago by marketing. It has a personal email from a form fill and no phone number.
Record B was created last week by enrichment. It has a verified work email, a direct dial, and a LinkedIn URL.
If you merge these and pick Record A as the master (because it has older activity history you want to keep), you need to manually select every enriched field from Record B during the merge. Miss one, and it's gone. There's no "merge and keep all populated fields from both records" button. You're manually picking field by field.
At scale, this is where data gets lost. A rep merging 20 duplicate pairs in a single sitting starts clicking fast. They pick the master, accept the defaults, and move on. The defaults keep the master's field values, not the duplicate's. If the enriched data was on the duplicate, it vanishes.
What to do before merging enriched records
Export both records first. Run a report or export the two records to a spreadsheet before merging. If you lose a field value, you can find it in the export.
Pick the more recently enriched record as master when possible. If the newer record has better data, making it the master means the defaults will preserve the enriched fields. You'll still need to manually keep any useful data from the older record, but there's usually less of it.
Check phone numbers and emails specifically. These are the fields most likely to differ between an older marketing record and a freshly enriched one. They're also the fields your reps need most.
Consider the activity history. The reason people sometimes pick the older record as master is to preserve the activity timeline. Both records' activities do transfer to the master, so this concern is usually misplaced. Pick the record with the better data as master.
Setting this up: the minimum viable configuration
If you're running enrichment into Salesforce and you haven't touched duplicate management, here's where to start. This takes about 30 minutes.
Step 1: Activate the standard matching rules. Go to Setup, search for "Matching Rules," and activate the standard rules for Leads and Contacts. These cover name and email matching out of the box.
Step 2: Set the standard duplicate rules to Block for API-created records. Go to Setup, search for "Duplicate Rules." Edit the standard Lead and Contact duplicate rules. Under "Record-Level Security," make sure the rule runs on create. Under "Action on Create," set it to Block for records created via API (this catches enrichment tool inserts). Keep Alert for records created manually.
Step 3: Create a custom matching rule on email (exact match). The standard rules use a combination of fields with fuzzy logic. Create a simple rule that checks email field with exact matching only. This catches the most common enrichment duplicate: same person, same email, pushed twice by different tools or different reps.
Step 4: Run a duplicate job on your existing data. Salesforce has a built-in duplicate job feature that scans your existing records against your matching rules and generates a report of potential duplicates. Run this before turning on blocking rules so you can clean up what's already there. One limitation: Salesforce caps duplicate job results at 1,000,000 total duplicates across all completed jobs. If you hit that limit, delete old job results before running a new scan.
Step 5: Merge carefully. Work through the duplicate report. For each pair, check which record has the better enriched data. Pick that one as master. Verify the field values before confirming the merge.
What this doesn't solve
Native Salesforce duplicate management won't catch everything.
It won't match across objects. If the same person exists as a Lead and a Contact, the standard duplicate rules won't flag it. Cross-object matching requires either a third-party tool or a custom solution.
It won't deduplicate against external systems. If the same person is in your Salesforce, your marketing automation platform, and your outreach tool, Salesforce only sees its own records.
It won't handle fuzzy email matching well. If the same person has john@acme.com and j.smith@acme.com, an exact email match won't catch it. Fuzzy email matching exists but generates too many false positives to be useful at scale.
For teams with complex deduplication needs, third-party tools like Plauti, Cloudingo, or DemandTools add cross-object matching, bulk merge capabilities, and more sophisticated matching algorithms. But for most teams just starting with enrichment, the native tools are enough to prevent the worst of the duplicate problem.
The bottom line
Build your duplicate rules before you turn on enrichment. Not after. The 30 minutes it takes to configure matching rules and duplicate rules will save you weeks of cleanup later.
If you want to test ShareCo's waterfall enrichment, it's free for 10 email enrichments and 3 phone enrichments through the Chrome Web Store. But set up your duplicate management first. Good data in a messy CRM is still a mess.