Almost Built a Five-Way Mapping Table. The Answer Was Already One Flow Upstream.

The Problem

A required field with nothing populating it, blocking the standard conversion path every time.

A rep flagged — twice — that converting a Lead into an Opportunity was throwing an error. The root cause was straightforward once traced: Customer Type on the Opportunity was a required field on the page layout, but nothing populated it automatically at the moment of conversion. Reps were expected to fill it in manually before the Convert button would even let them proceed, and the direct Lead-to-Opportunity conversion path hit that wall every time.

The First Plan — And Why It Got Scrapped

A new field and a five-way mapping table, until the platform said no.

The instinct was to build a new Lead Type field with a handful of values, then map it onto the Opportunity's existing Customer Type field, which carried five values of its own. That got complicated fast:

• Customer Type turned out to be multi-select, which meant Salesforce's native lead-field mapping tool couldn't bridge a single-select Lead field to a multi-select Opportunity field at all — a hard platform limitation, not a workaround
• Even routing around that with a Flow, the Lead Type values didn't map cleanly onto the five Customer Type values — two of them had no obvious home, and a mapping table introduces exactly the kind of complexity a required-field fix shouldn't need

The Insight That Simplified Everything

A Lead converted the normal way is always net-new. Something upstream already knew that.

A Lead converted through the standard path — with a new Opportunity created — is always net-new. Existing-customer inquiries get caught and routed by an existing domain-matching flow before conversion ever happens, and typically don't get a fresh Opportunity created at all, since one already exists.

That meant the entire Lead Type field and its five-way mapping were solving a problem that had already been solved upstream. The status field set by that existing flow already captured everything needed: a verified net-new result meant the Opportunity was a Prospect; a pending-review-as-existing-company result meant it was an Existing Customer. No new field. No mapping table. Just read a value that already existed.

The Build

One new picklist value. One record-triggered flow on the conversion transition.

• Added a "Prospect" picklist value to the Opportunity's Customer Type field
• Built a record-triggered Flow on Lead, firing on the conversion transition: pull the converted Opportunity, branch on the upstream flow's status field, add the mapped value to Customer Type using the multi-select Add operator, and save the update back to the Opportunity

Two Bugs Found in Production, Not Sandbox

Sandbox passed clean. Production surfaced two timing problems sandbox never could.

Sandbox testing passed cleanly across all three paths — Prospect, Existing, and blank / no-match. Production immediately surfaced two issues sandbox hadn't:

• Timing race — the flow fired before the conversion transaction had actually written the new Opportunity's ID back to the Lead, so the record lookup found nothing and the update failed with a null-ID error. Fixed by moving the logic onto a one-minute scheduled path instead of running immediately, giving the conversion transaction time to fully commit first
• No-Opportunity conversions — existing-customer Leads are often converted without creating a new Opportunity at all, since one already exists, which meant that ID field stayed permanently null rather than just delayed. Fixed by adding a second entry condition so the flow simply never starts on conversions that didn't create an Opportunity

The Outcome

Customer Type fills itself in about a minute after conversion. No new field. No mapping table.

All three scenarios — Prospect, Existing, and a blank upstream status — are tested and confirmed working in production. The original conversion error is resolved for the standard conversion path, and Customer Type now auto-populates roughly a minute after conversion instead of requiring manual entry, closing the gap without adding a new field or a mapping table. Both production-only edge cases were caught and fixed live rather than in sandbox — a reminder that conversion-triggered automation can behave differently under real transaction timing than it does in a sandbox test.

Open Items

Two known gaps, left open on purpose.

• Opportunity Name auto-generation still produces a trailing dash with nothing after it on some converted records. Not blocking — reps can edit the name during conversion — but the underlying cause, likely a Lead Company field value that already contains a dash, hasn't been root-caused yet
• No fallback exists for Opportunities where the upstream status field is blank at conversion — Customer Type stays blank, and the rep hits the original required-field error again on their next manual edit of that record, just later than before. Acceptable given how infrequently this occurs, but worth revisiting if it becomes a pattern

What Was Built

• Prospect picklist value added to the Opportunity's Customer Type field
• Lead Conversion – Auto Set Customer Type flow — record-triggered on the Lead's conversion transition
• Scheduled-path timing fix — one-minute delay added so the flow reads the Lead after the conversion transaction fully commits
• Entry-condition fix — flow skips conversions that didn't create a new Opportunity, closing the null-ID failure path
• Two open, non-blocking issues documented for future revisit: a cosmetic Opportunity-naming artifact and a blank-status fallback gap
• Stack: Salesforce Flow Builder · Lead Conversion · Opportunity