On a recent residential real-estate implementation, the sales team came to me convinced lead conversion was broken. They were converting Facebook leads into opportunities exactly as trained, but the opportunities kept landing in the pipeline with half their fields blank. Budget range, project interest, expected move-in date, all the things a sales manager actually forecasts on, were simply not there. The reps assumed they'd missed a step. They hadn't. The conversion was being triggered through an automated flow for hot leads, and custom field mapping does not apply when conversion runs anywhere except the standard UI.
That single gotcha is a good illustration of why lead conversion deserves far more respect than it usually gets in a project plan. On paper it's one button. In practice it's an irreversible, multi-object data-merge operation that inserts or updates an Account, a Contact, and optionally an Opportunity, creates a primary contact role, migrates activities, and stamps the original lead as converted forever. Every one of those steps has a way to quietly lose or mangle data, and most of the failures don't throw an error. They just produce thin records that nobody notices until a report looks wrong three weeks later.
What follows is the set of failure modes I now check for on every Sales Cloud engagement, drawn from real conversion work across a property developer and a wealth-management cross-sell program. None of these are exotic. They're the boring, repeatable ways conversion loses data.
Conversion through Flow or API is not the conversion you tested
The most expensive misunderstanding I see is the assumption that the field mapping you configure under Object Manager and Lead Convert Settings is a global rule. It isn't. That mapping is a property of the standard conversion UI. The moment conversion happens through a record-triggered flow, an Apex Database.convertLead call, or the REST LeadConvert resource, Salesforce copies only the standard mappings (company to account name, name and email to contact, and so on) and ignores every custom field mapping you defined.
For the real-estate client, the integration that pushed qualified Facebook leads in and auto-converted them did exactly this. The opportunities came out empty because nobody had copied the custom fields after the convert call. The fix is straightforward once you know to look for it: in the same transaction that performs the conversion, query the source lead and explicitly set the destination fields on the new Opportunity (or Contact). If you're building this with a flow, that means an after-save step on the Opportunity that reads CreatedFromLead, pulls the lead values, and writes them across. The point is that auto-conversion must be tested as its own path, with assertions on the destination fields, because it behaves differently from the button your reps clicked during UAT.
While you're in that flow, audit the Opportunity owner too. Conversion defaults the new Opportunity's owner to the lead owner, which is usually what sales wants, but Account Team mapping or a legacy assignment trigger can silently override it and hand the deal to the account owner instead. I've watched a rep lose an entire pipeline that way. The fastest check is to convert one lead in a sandbox and compare Opportunity.OwnerId against Lead.OwnerId.
Field mapping fails in ways that don't announce themselves
Even pure UI conversion drops data when the source and destination fields don't agree, and Salesforce is inconsistent about whether it warns you. Some mismatches hard-block, others fail silently, and you need to know which is which.
A type mismatch is the loud failure. If the lead field is a Number and the opportunity field is a Currency, Salesforce refuses to save the mapping at all. You either change the destination type, losing currency conversion in a multi-currency org, or you leave the types as they are and copy the value with a flow after conversion. For multi-currency clients I almost always take the second route, because giving up currency handling on a financial field is the worse trade.
The quiet failures are the ones that hurt. A multi-select picklist maps fine if both value sets match exactly, but if the destination is a restricted picklist with even one different value, the mismatched entries are dropped on convert without any message. Sales doesn't see it, the record looks populated, and the report under-counts. Formula fields are another trap: a formula isn't a stored value at conversion time, so you can't map it into a plain text field on the Opportunity, and the workaround is a destination text field that a flow recalculates after the fact. Lookup fields mostly behave (a lead's campaign attaches to the opportunity automatically), but any lookup that has no equivalent on the target object, like a lead-to-lead referral, has nowhere to land and needs a custom field plus logic to resolve it. The discipline here is to walk every source-to-destination pair before go-live and confirm not just that a mapping exists, but that the value actually survives the trip.
Duplicate handling has to be designed, not switched on
Conversion is one of the highest-risk moments for duplicate creation, because a rep under time pressure will happily click "Create New Account" without checking whether that account already exists. Salesforce will apply your Duplicate Rules during conversion, but only if you've explicitly ticked "Apply to Lead Convert" on the rule. Miss that checkbox and the rule runs on manual edits and never fires on the conversion path you actually cared about. I check that box on every duplicate rule by reflex now.
The harder problem is that matching rules aren't strong enough on their own for messy real-world names. On the wealth-management project, a company lead written one way ("Cong ty TNHH A Chau") failed to match an existing account written another way ("CTY TNHH A CHAU") because the fuzzy distance fell below the default threshold, and that threshold isn't something you can lower in standard Duplicate Management. Rather than reach for a managed package, the practical fix was to normalize the company name before conversion: strip the legal-entity suffixes and accents into a Company_Normalized__c field with a flow, and have the matching rule compare on the normalized field. Normalizing the match key reliably beats fighting the matcher.
On the action setting itself, I default to Allow with Alert rather than Block. Blocking conversion outright frustrates reps and generates support tickets when the "duplicate" is a legitimate distinct record. Alert gives the rep the warning and the option to link to the existing record, which on the wealth side was exactly the behavior the business wanted: when a Wealth lead was already a retail Contact, the rep saw the alert and linked into the existing account instead of spawning a second one.
Skipping the Opportunity breaks attribution unless you plan for it
Plenty of legitimate processes don't create an Opportunity at conversion. The wealth advisors converted leads into an Account and Contact first and only created the Opportunity weeks later, after a discovery meeting. That's a perfectly reasonable sales motion, but it severs the link between the eventual deal and the lead that originated it, because an opportunity created by hand has no idea a lead ever existed. Conversion-rate and source-effectiveness reporting quietly fall apart.
The pattern I use is to carry the lead reference forward through the Account. When a rep converts and skips the Opportunity, a flow stamps the lead's id onto the Account. When an Opportunity is later created under that account, another flow copies the reference into a Source_Lead__c lookup on the Opportunity. Now the chain holds and source attribution survives the gap. It's worth asking up front whether skipping is occasional or routine, because if it's routine you also want a reason field on the skip so the business understands why so many leads convert without a deal attached.
Treat conversion as one-way and verify before you trust it
The thread running through all of this is that conversion is irreversible and partly silent. Salesforce has no un-convert; once IsConverted flips true, the lead is read-only and your only recourse is recreating records and flagging the mistake. That permanence is exactly why I refuse to take conversion on faith. Before any go-live I run the same drill: convert ten representative leads covering B2B and B2C, leads with and without a company, leads with and without a phone; check that custom fields landed, that activities followed the contact, that the opportunity got the right record type, stage, owner, and campaign, and that the conversion-rate report actually reconciles. Conversion is the seam where your lead funnel becomes your pipeline, and a seam that loses data is one you pay for in every forecast downstream.
Implementing or optimizing Sales Cloud? Our Salesforce team runs discovery, designs the sales process, and configures Sales Cloud on production engagements. Get in touch ->
See our full platform services for the stack we cover.
