Salesforce Lead Conversion Duplicates: Fix the Handoff

Salesforce lead conversion duplicates are not a discipline problem, and your reps are not being careless. Conversion is the single highest-volume write path in most orgs where a brand-new Account and Contact get created at the click of a button — and it is one of the paths Salesforce explicitly documents its own duplicate rules as not running on. The rep does everything right. The org grows a second Acme anyway. If you have ever run a count and found four Accounts for one customer, three of them created within days of a deal being worked, this is where they came from.

The convert button is doing exactly what it was told

Picture the sequence, because the sequence is the whole story. A lead comes in from a form fill: Sarah Chen, Acme Inc. Your org already has an Account called Acme, Inc. with eleven Contacts and two closed-won Opportunities on it. The rep opens the lead, clicks Convert, and Salesforce offers to create a new Account.

Not because the match logic failed. Because there was no match logic. Salesforce is comparing the text in the lead’s Company field against Account names, and Acme Inc is not the same string as Acme, Inc. — the comma and the period make it a different company as far as that comparison is concerned. The rep is presented with a perfectly reasonable-looking screen that says “Create New Account: Acme Inc,” and they click through it, because nothing on that screen tells them a home for this person already exists.

Twenty minutes later the same thing happens with a lead from acme.com whose Company field says Acme Corporation. Now you have three.

The second Contact is worse than the second Account

Duplicate Accounts are visible. Somebody eventually notices two Acmes in a list view and files a ticket. The duplicate Contact created underneath them is the one that costs you money, and it is nearly invisible.

Sarah Chen was already in the org — she filled out a webinar form fourteen months ago and got converted then, too. Now there are two Sarah Chens: one on Acme, Inc. carrying the activity history, the campaign membership, and the note from the AE about her budget cycle, and one on Acme Inc with nothing on it except today’s conversion. Your sequences will now email both. Your reports will count her twice in the funnel. The rep working the new Opportunity will see a contact with no history and conclude this is a cold first touch, and they will open the call accordingly.

That is the real cost of conversion duplicates. Not storage. Not tidiness. You lose the institutional memory attached to a person at the exact moment somebody is about to pick up the phone.

What you need is a decision made before Convert runs

The fix is not a better warning on the conversion screen. It is a step that happens before the screen, which answers one question: does this person, at this company, already exist in this org — under any of the spellings and domains we actually use?

Concretely, what gets built is a match-and-resolve step that runs against the lead and returns a verdict:

• Company resolution on the signals that actually identify a company — email domain first, then a normalized form of the company name (lowercased, punctuation stripped, inc/llc/ltd/corp and trailing the removed), then the website field, then any account number or external ID your systems already share. Acme Inc, Acme, Inc., ACME Corporation and acme.com all resolve to one Account.
• Person resolution inside the resolved Account — email exact match first, then normalized first+last name, then a phone match on digits only. Nicknames handled by a small alias list you control, because Sarah and Sari and S. Chen are a business decision, not a string-distance problem.
• A verdict with a reason. Not just “duplicate” — matched to Account 001xx on email domain acme.com; matched to Contact 003xx on email exact. The rep sees why, which is what makes them trust it.
• The branch. Confident match: convert into the existing Account and Contact, merging the lead’s new field values onto the existing record rather than over it. No match: create, and stamp the normalized keys on the new records so the next lead matches this one. Ambiguous: surface the candidates and let the human choose, because a forced guess on an ambiguous match is how you merge two real customers into one.

The outcome is that a rep clicking Convert lands on the record that already has the history, and the org stops growing a new Acme every quarter. That is the entire deliverable, and you can describe it to someone in one sentence.

Salesforce documents the gap, and it’s easy to miss

This is worth reading in Salesforce’s own words, because most teams turn duplicate rules on and reasonably assume they are covered. Salesforce’s Things to Know About Duplicate Rules lists the cases where the rules do not run, and one of them is exactly this: “Leads are converted to accounts or contacts, and Use Apex Lead Convert isn’t enabled.” The same page lists data import tools, records added or edited through the APIs, undelete, manual merges, and Quick Create — and caps you at five active duplicate rules per object.

So the feature works. It just does not watch the door your duplicates come through. The considerations for converting leads are equally candid: “When you convert leads to contacts or accounts, the process sometimes creates duplicate records. If so, we show you a warning” — and on matching, only that “if existing accounts and contacts share the names specified on the leads, you can choose to update the existing accounts and contacts.” Share the names. That is the mechanism. Everything in the section above about commas and domains follows from that one sentence.

I wrote about the broader version of this problem in Salesforce duplicate management rules that actually fit — the five-rule ceiling, the import path, the merge. This post is the conversion door specifically, because it is the one with a rep standing at it.

The native switch is an org-wide lever, not a fix

There is a way to make duplicate rules fire during conversion, and you should know what it actually costs before you request it. Salesforce’s guidance on enabling Use Apex Lead Convert points to Setup → Lead Settings, where you can turn on “Require Validation for Converted Leads,” or have Support activate Use Apex Lead Convert where that option isn’t available.

Read the side effects. Enabling it lets “validation rules, workflow rules, and triggers to run during lead conversion” — which sounds like an unambiguous win until you notice that it “will also affect Process Builders, Workflows, Apex Triggers, Required Field Settings, and validation rules,” and that it “may also remove previous conversion Field Mappings if enabled.” Salesforce’s own advice is to document your field mappings first and then verify “that no unintended validation rules are blocking conversions.”

In an org of any age, that is not a small switch. Every required field somebody added to Contact in 2023 now has to be satisfiable from a lead. Every validation rule written on the assumption that conversion bypassed it is suddenly in the path. Teams flip it in a sandbox, watch conversions start failing on rules nobody remembers writing, and flip it back — which is a completely rational response, and leaves them exactly where they started.

And even when it is on, you get duplicate rules: five per object, matching on the fields Salesforce’s matching rules support, with none of the domain-first company resolution or alias handling that made the difference above. It closes the door; it doesn’t install the lock you wanted.

The rules your match step can hold that five can’t

Once the decision lives in a step you control, the policy can finally be as specific as your business actually is:

• Domain beats name, except for the domains where it doesn’t. Gmail, Outlook, Yahoo and the rest can never resolve a company — and neither can the shared domains of the franchise groups, holding companies and MSPs where fifteen genuinely separate customers share one email domain. That exception list is three lines in a match step and impossible to express in a matching rule.
• Parent and child are not duplicates. Acme Northeast and Acme Southwest are two Accounts on purpose. A match step can resolve to the right child by territory or billing state; a name-similarity rule sees one duplicate and stops.
• Recency matters. A lead matching a Contact whose Account has been dormant for three years is a different situation from one matching an open Opportunity. Same match, different handling, and the rep should be told which one they’re in.
• The lead’s new data is worth keeping. Sarah’s new title and direct dial arrived with this lead. Converting into the existing Contact should fill empty fields and log the changed ones, not silently discard the fresher values or overwrite a manually-corrected one.

None of that is exotic. It is the ordinary shape of a real company, and it is more than five flat rules can carry. It is also more than Flow wants to hold — the normalization and the candidate ranking are loops and string work, which is the point where Flow gives way to Apex whether or not anyone wanted it to.

The ones you already converted

Fixing the door does nothing about what walked through it, and the cleanup is a separate, finite job worth scheduling right after.

The count comes first, and it is a query, not a project: group Accounts by normalized name and by the email domain of their Contacts, and count the groups with more than one. Then the same for Contacts within each resolved Account group. That number is the one to take into the room, because “we have some duplicates” loses every prioritization argument and “we have 610 Accounts that are really 240 customers, and 1,900 Contacts that are really 1,400 people” wins it. If pulling that count is itself the blocker, that’s the report you’ve been told you can’t build problem, and it’s solvable the same way.

Then merge in batches, oldest and least-active groups first, with the survivor chosen by a rule you wrote down — most activity, or oldest, or the one with the open Opportunity — and the merge logged so you can see what folded into what. Salesforce’s own note that duplicate rules do not run on manual merges is a reminder to be deliberate here. This is the same shape of work as any bulk update without a Data Loader marathon: reversible in batches, verified between them, rather than one heroic weekend.

Why nobody has built this yet

Every Salesforce admin reading this already knows what the match step should do. The reason it doesn’t exist is not knowledge and it is not priority. It’s that “write a pre-convert matching service with normalized company resolution, an alias list, candidate ranking and a UI for the ambiguous cases” is a two-to-four-week ticket in a queue where the CRO’s pipeline report is ahead of it, and lead conversion duplicates are a slow leak rather than an outage. So it never reaches the top, and the org keeps growing a new Acme every quarter. The constraint has always been developer capacity, not developer knowledge.

That is the arithmetic that changed. When you can describe this to an AI that can actually read your org — your Account naming conventions, your existing duplicate rules, the field mappings you’d be risking — and then write, test and deploy the Apex sandbox-first, the two-week ticket becomes an afternoon of iteration. You are still making every real decision: which signals identify a company, which domains can never resolve one, who wins a merge. You just stop waiting for a calendar slot to get them implemented.

The reason it’s safe to iterate on something this close to your customer data is that the work is visible and recoverable rather than restricted. Every change your AI makes is logged with who and when, a snapshot is taken before each deploy, and Salesforce changes go to a sandbox with tests before they go to production — so a matching rule that resolves too aggressively is a thing you find in the sandbox and roll back, not a thing you discover in six months of merged customers. That is the whole argument for letting an AI near this: not that it can’t make a mistake, but that you can see it and undo it. The full version of how that works is in how AI-written changes stay safe to deploy, and the practical setup is giving your AI write access to the org.

Where to start

Do the count before you build anything. Normalized Account names, grouped, counted. It takes an hour and it tells you two things: how big the debt is, and — from the shapes of the collisions — which signals your match step actually needs. If every collision is punctuation, normalization alone fixes most of it. If they’re all subsidiaries and franchise groups, you need the parent-child rules first and normalization second. You cannot know which org you have until you look.

Then build the match step for the confident cases only, and route everything ambiguous to a human. A step that resolves 70% of conversions correctly and asks about the other 30% is worth deploying next week. A step that tries to resolve 100% silently is how two real customers get merged, and one of those mistakes costs more trust than the duplicates ever did.

And leave Use Apex Lead Convert alone until you’ve read your own validation rules. It is the right switch for some orgs and a week of unexplained conversion failures for others, and the difference is knowable in advance — which is itself a good first thing to ask your AI to go find out. While it’s in there, having it tell you what your assignment rules do on conversion is worth the same hour; lead routing and round-robin assignment break in the same place for the same reason, and one trip through the org can map all three.

Pricing is flat per Sentinel and is covered on a short demo call.

Book a Demo Call and bring the duplicate count. If you don’t have it yet, bring the two spellings of your biggest customer — that’s the same conversation.