Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

A stage is a picklist value on Opportunity that carries three passengers with it: a default probability, a forecast category, and an open or closed flag. Most orgs have too many stages, treat probability as if it were a real number, and then build automation that assumes stages only ever move forwards. All three of those age badly.

What a stage actually is

OpportunityStage is a standard setup object, not an ordinary picklist. Each value has:

  • MasterLabel, the value users see.
  • DefaultProbability, which populates the Probability field on the opportunity when the stage changes.
  • ForecastCategoryName, one of Omitted, Pipeline, Best Case, Commit and Closed.
  • IsClosed and IsWon, which drive nearly every standard report and the Won or Lost logic everywhere else.

You cannot invent a sixth forecast category, and you cannot have a closed stage that is neither won nor lost. Orgs wanting a “Closed, dormant” state end up with a separate status field.

Probability is a default, not a calculation

Probability is an editable percentage field. Changing the stage overwrites it with the stage default. Editing it by hand afterwards sticks, until the next stage change wipes it again. That single behaviour explains most of the confusion around it.

So probability is not a per-deal judgement in practice. It is the stage wearing a number. Weighted pipeline, calculated as Amount times Probability, therefore tells you about your stage distribution and almost nothing about individual deals. Salesforce ships that calculation as the standard ExpectedRevenue field, which you cannot change.

How many stages

Six to eight, including the two closed ones. Beyond that, stages describe internal tasks rather than buyer state. The symptom is stages named after things your team does (Demo Booked, Proposal Sent) rather than things now true about the deal (Budget Confirmed, Vendor Selected).

Activity-named stages break as soon as the sales process changes, because the stage list has encoded the process. Buyer-state stages survive it.

Forecast category mapping

Forecast category comes from the stage and can be overridden per opportunity, but the next stage change resets it. A sane mapping puts early stages in Pipeline, the stage where a deal becomes genuinely likely in Best Case, the late stage in Commit, Closed Won in Closed and Closed Lost in Omitted. Putting anything early into Commit makes the forecast meaningless within a quarter.

Why stage-based automation ages badly

The tempting build is a flow on Opportunity that fires when Stage changes to a specific value, creates tasks, sends notifications and updates fields. It works for about a year.

What breaks it:

  • Backwards moves. Deals slip. A flow keyed on entering a stage fires again on the second entry, creating duplicate tasks. Guard with a check on PRIORVALUE(StageName) or a helper field recording the furthest stage reached.
  • Skipped stages. A rep drags from stage two to stage five in Kanban. Anything assuming stage three ran never happened.
  • Renaming. Changing a stage label is a business decision made in a meeting you were not in. Every flow, validation rule and report filter comparing StageName to a hard-coded string breaks silently, because a comparison against a string that no longer exists is simply false rather than an error.

The defence is to stop comparing labels. Use IsClosed and IsWon where they answer the question, and drive any specific-stage comparison from custom metadata so the value lives in one place.

SELECT Id, MasterLabel, IsActive, IsClosed, IsWon,
       DefaultProbability, ForecastCategoryName, SortOrder
FROM OpportunityStage
ORDER BY SortOrder

Run that against any org you did not build. One query gives you the whole stage model, including inactive values still sitting on old records.

Validation at stage boundaries

Requiring fields at a stage means a validation rule referencing the stage, not a page layout. Layout-level required fields apply everywhere, which is why “required at Proposal” becomes “required at creation”.

Keep those rules few. Every required field at a boundary is a reason for a rep to leave the deal in the previous stage, and a pipeline understated by your own validation rules is worse than one with blank fields.

Frequently asked

Can I delete a stage? You can deactivate it, and Salesforce asks you to replace it on existing records. Deactivating without replacing leaves records holding an inactive value, which reports on but cannot be re-selected.

Does changing DefaultProbability update existing records? No. It applies from the next stage change onwards. Existing opportunities keep the probability they were given.

Can different record types have different stages? Yes, that is the standard way to run two sales processes. Each sales process selects a subset of stages, and a record type points at one sales process.

Should Closed Lost be Omitted or Closed? Omitted. Closed as a forecast category means closed won revenue, and putting losses there inflates every forecast roll-up.