Asked to Build a New Pipeline. Found a Record Type Gap That Had Been Invisible for Years.

The Ask

Every deal — software or services — ran through the same six stages built for software.

The organization had never separated Services opportunities from its core Software pipeline in Salesforce. Every deal — regardless of whether it was a core software sale or a hands-on services engagement like implementation, migration, training, or managed services — ran through the same six-stage sales process, using fields and stage names built for software deals.

Leadership wanted a dedicated Services pipeline: its own stages, its own required fields at each stage, and enforcement so deals couldn't silently skip steps like NDA collection or SOW sign-off. Alongside that, 79 services opportunities sitting in a separate task-tracking tool — never entered into Salesforce — needed to be reconciled and loaded.

The ask arrived with a hand-drawn stage diagram, a spreadsheet, and the instruction that the data load was needed the same day.

The Ask, As Written

Two requests, framed as one same-day task.

• Build a new Services stage set — a diagram showed six proposed stages (Opportunity, Qualification, Proposal, Closing, Closed Won, Closed Lost), each with fields that should be required before a deal could advance
• Load 79 opportunities from an external list — a spreadsheet of deals sorted by proximity to close, needing to be matched against existing Salesforce records or created fresh

Both were framed as needed the same day.

Surfacing the Real Scope

The stages in the diagram didn't exist yet. The data load depended on stages that hadn't been built.

The gap between the request and what it actually required became clear almost immediately.

• The proposed stage names didn't exist in Salesforce yet — the diagram's stages were aspirational, none were real picklist values. The data-load spreadsheet had already been built assuming these stages existed, meaning the load and the stage build were sequentially dependent, not parallel tracks
• "Needed today" didn't match the actual technical scope — standing up a second Sales Process, a new Record Type, field-level enforcement, and document-upload automation isn't a same-day build if done responsibly, and building it carelessly risked breaking the live Software pipeline every rep was actively using

This was raised directly and in writing before any build work began: the data load was achievable same-day; the stage and field architecture was not.

Record Type vs. Sales Process

Stage is one shared field across the whole org. Record Type is a lens on top of it, not a new field.

A key early misconception, worth naming because it shaped the whole build: Salesforce's Stage field is a single, shared field across every Opportunity in the org — there's no way to give Services its own independent Stage field. What actually creates separation is a new Sales Process, a named, curated subset of Stage values, paired with a new Record Type, which determines which Sales Process — and therefore which subset of Stage values — a given rep sees in their dropdown.

Record Type doesn't create a new field. It's a lens on top of one shared field. That distinction mattered later, when a pre-existing data issue caused the entire historical Stage picklist to leak into records that weren't properly typed.

Avoiding Duplicate Fields

Auditing before building cut an initial 13-field list down to 8.

Before building anything, the Opportunity object's existing fields were audited against the diagram's required-fields list. This caught several near-duplicates before they were built:

• Several fields the diagram called for already existed under different names — reused instead of rebuilt
• The org already had three separate loss-reason fields from prior, uncoordinated builds — a pre-existing hygiene issue, deliberately left alone rather than adding a fourth
• A Type field (Software/Services) and a default value were both considered and ultimately rejected — Record Type already fully distinguished Services from Software, and reports can filter and group on Record Type directly, so an auto-populated Type field would have been redundant data serving no additional purpose

Net result: of an initial 13-field build list, only 8 fields were genuinely new.

Enforcing "Required," and Where Validation Rules Hit a Wall

Two required fields couldn't be enforced with a validation rule — so they weren't, on purpose.

The diagram's stage plan showed dotted "Required" brackets — fields that must be filled in before a deal could advance. The natural tool for this is a validation rule. Two of the required fields, however, are multi-select picklists, and Salesforce's validation rule formula engine does not reliably support blank-checking on multi-select fields, even using documented workarounds.

Rather than fight platform limitations for marginal gain, those two were enforced via page-layout required instead of a validation rule — a deliberate, documented trade-off, bypassable via API or import unlike a true validation rule, rather than an oversight.

Turning "Uploaded" Checkboxes Into Something Trustworthy

A checkbox anyone can check isn't proof of anything. So the checkbox became a byproduct, not a claim.

The diagram called for checkboxes like "NDA Uploaded" and "MSA Uploaded." A plain checkbox has an honesty problem: nothing stops a rep from checking the box without actually attaching a document. The fix was four Screen Flows, each triggered by a dedicated Quick Action button. Each Flow presents a file-upload component scoped to the current record, and only checks the corresponding box once a real file has landed on it — making the checkbox a byproduct of the upload, not a manual claim.

Four separate buttons, rather than one button with a document-type dropdown, were chosen specifically to remove the chance of a rep mislabeling which document they'd uploaded.

Bugs Caught Through Live Testing

None of these would have surfaced from a code review.

They only showed up by actually clicking through real records:

• Wrong field referenced in a validation rule — the Closed Lost gate was built against one loss-reason field, but the field actually on the layout was a different one entirely, a casualty of the pre-existing three-field loss-reason mess. The rule would have silently never blocked anything. Caught by testing a real Closed Lost save and noticing it succeeded when it should have failed
• An edited Flow that was never re-activated — the MSA Upload Flow was fixed and saved, but the new version sat inactive, meaning the old, broken version kept running during testing and produced a false "still not working" result. Diagnosed by checking the Flow's version history directly rather than re-reading code that looked correct
• A naming mix-up mistaken for a functional bug — a Flow's update step appeared to reference the wrong checkbox mid-build. It turned out to be a narration error, not an actual misconfiguration, caught and clarified before wasting time "fixing" a non-issue

Deployment

One component looked deployable and wasn't. Post-deploy verification caught it.

The build was packaged into a single production change set: Record Type, all new fields, the Services-specific page layout, a dedicated Lightning Record Page, four Flows and Quick Actions, and four validation rules. One component didn't survive the change set as expected — the Sales Process showed in the component list but didn't deploy cleanly, and was rebuilt manually in production in under five minutes. A reminder that Salesforce change sets, even when a component looks deployable, warrant post-deploy verification rather than blind trust.

The Discovery: A Data Integrity Gap That Had Existed for Years

The entire sales org had been defaulting to Salesforce's internal fallback Record Type. For every deal. For years.

While configuring which user profiles could see the new Service Opportunities Record Type, a much bigger, entirely unrelated problem surfaced: the sales team's profile had never been assigned the org's existing standard Opportunities Record Type. Every AE — the whole active sales org — had been defaulting to Salesforce's internal fallback ("Master") for every opportunity they'd ever created. Only admin accounts had the correct Record Type properly assigned.

The practical effects:

• Every opportunity created by any rep may have been invisible to any report, list view, or automation that filtered specifically on the correct Record Type
• Records on the fallback type don't inherit Sales-Process-based Stage filtering — meaning editing any existing opportunity showed the organization's entire historical Stage picklist at once, old stages and brand-new Services stages together, a symptom initially mistaken for a bug in the new build, but actually a downstream consequence of this pre-existing gap

This had almost certainly existed for years, invisible because the fallback type still rendered a normal-looking layout — nothing was ever visibly broken, so nobody had reason to look.

Resolution

Fixed the same day it was found, and proven live on a real record.

Flagged immediately to leadership, fixed the same day once approved — the correct Record Type was set as the default for the sales profile, and verified live with an active rep successfully creating a properly-typed opportunity. The fix addresses all new records going forward; a mass reassignment of historical, incorrectly-typed records remains a separate, still-open decision.

One live opportunity — an $8.3M Services RFP that had been miscategorized under the old Software process — was manually converted to the correct Record Type and Stage as a proof point, preserving its full activity and stage history through the conversion.

Validation

Two independent checks, not just the builder's own testing.

• A services-side reviewer walked through the build live via screen share and confirmed the stages, fields, and layout matched how services work is actually run
• A live sales rep confirmed he could create a Service Opportunity himself under his own, non-admin login — proof the Record Type, profile, and layout chain worked end-to-end for a real user, not just an administrator

The Outcome

A separated pipeline, live and validated — plus a years-old gap found and closed as a byproduct.

• A fully separated Services sales pipeline — its own six stages, required-field enforcement at each transition, and automated document-upload tracking — live in production and validated by both a domain expert and a real end user
• A pre-existing, org-wide Record Type misconfiguration, invisible for years, found and fixed as a direct byproduct of building something else
• The 79-opportunity reconciliation in progress, using a hybrid approach: manual search-and-match against Salesforce first, to avoid the very duplicates a bulk tool could silently create, followed by a single clean bulk load for confirmed-new records

What Was Built

• New Services Record Type, Sales Process, and six-stage picklist, separated from the core Software pipeline
• 8 new Opportunity fields shipped, down from an initially-scoped 13 after a duplicate-field audit
• Page-layout-required enforcement on two multi-select fields validation rules couldn't reliably blank-check
• Four Screen Flows and Quick Actions turning document-upload checkboxes into a byproduct of a real upload, not a manual claim
• Four validation rules gating stage advancement on required fields
• Org-wide default Record Type misconfiguration found and corrected for the entire sales profile
• Stack: Salesforce Flow Builder · Record Types · Sales Processes · Validation Rules · Screen Flows