Configuring Salesforce opportunity management: sales stages, sales processes, opportunity record types, Path configuration, opportunity teams, opportunity splits, and forecasting categories. Use when setting up or restructuring the opportunity lifecycle for Sales Cloud. NOT for Collaborative Forecasts setup (use collaborative-forecasts skill). NOT for CPQ pricing or product configuration (use Revenue Cloud skills). NOT for territory-based forecasting alignment (use enterprise-territory-management skill).
This skill activates when configuring or restructuring the opportunity lifecycle in Sales Cloud: defining stages, building sales processes, assigning them to record types, adding Path guidance, enabling team selling and splits, and aligning stages to forecast categories. The configuration chain has a strict dependency order — skipping or reversing steps causes broken picklists, forecast gaps, or data integrity issues.
Gather this context before working on anything in this domain:
Every Opportunity Stage is a global picklist value that carries four platform-enforced fields: IsClosed (boolean), IsWon (boolean), Probability (default, overridable per record), and ForecastCategoryName. These are set at the global picklist level in Setup > Opportunity Stages and are NOT overridable per sales process or record type.
ForecastCategoryName maps to exactly five fixed platform values: Pipeline, Best Case, Commit, Closed, and Omitted. These labels cannot be renamed. Stages mapped to Omitted are excluded from all forecast rollups. Stages mapped to Closed must also have IsClosed = true.
Deleting a stage picklist value while records still use it does not produce a validation error at deletion time — it silently corrupts existing records by leaving them with a blank Stage field. Always reassign records before deleting a stage value.
A Sales Process is a filtered view of the global Stage picklist. It controls which stage values are available on a record type. The dependency chain must be followed in this exact order:
A stage not assigned to a Sales Process cannot appear in any record type or Path built from that process. Path Settings add guidance and key fields per stage but do NOT enforce stage progression — enforcement requires separate validation rules.
Path is a visual component layered on top of a record type's available stages. It provides guidance text and up to 5 key fields per stage to prompt rep behavior. Path is configured in Setup > Path Settings and requires the record type and its sales process to be active first.
Path does not prevent reps from jumping stages. If stage progression must be enforced (e.g., Close Date cannot be blank until Proposal stage), use a validation rule with ISPICKVAL(StageName, 'Proposal') && ISBLANK(CloseDate) logic. Path and validation rules are complementary — Path guides, validation rules enforce.
Team Selling must be enabled before Opportunity Splits is enabled — this is a hard platform dependency. Once Team Selling is on, Sales Team member roles become available on records.
Opportunity Splits has two types:
Splits cannot be disabled after split data has been saved. This is a one-way door. Before enabling splits in production, confirm the business process permanently requires them.
When to use: The org serves different buyer motions (e.g., new logo, renewal, channel partner) that move through different stage sequences.
How it works:
RecordType.DeveloperName to enforce stage-specific field requirements per motion.Why not a single process: A single catch-all process forces reps through irrelevant stages and pollutes forecast data with stages that don't match the motion's pipeline semantics.
When to use: Multiple reps share credit on deals and the business needs their individual quotas reflected in forecasting.
How it works:
Why not use Opportunity Amount: Amount-based forecasting double-counts when multiple reps appear in splits. Split-based forecasting credits each rep's share.
| Situation | Recommended Approach | Reason |
|---|---|---|
| Two business motions with different stages | Separate Sales Processes + Record Types | Prevents stage contamination across motions; keeps forecast rollups clean |
| Need to guide reps on key fields per stage | Configure Path Settings | Path provides inline guidance without requiring custom page layouts per stage |
| Need to prevent reps from skipping required stages | Add Validation Rules (not Path) | Path is visual only — it does not block saves |
| Multiple reps need credit on a deal | Enable Revenue Splits | Splits feed forecast rollups per rep; Amount-only forecasting double-counts |
| Overlay team (SEs, pre-sales) need separate credit | Enable Overlay Splits + separate forecast type | Overlay totals can exceed 100%; they feed a distinct forecast type without affecting quota |
| Stage no longer used | Reassign all records, then deactivate — never delete while records use it | Deletion silently blanks Stage on existing records |
| Forecast category label needs renaming | This cannot be done — ForecastCategoryName values are platform-fixed | The five values (Pipeline, Best Case, Commit, Closed, Omitted) cannot be renamed |
Step-by-step instructions for an AI agent or practitioner working on this task:
python3 skills/admin/opportunity-management/scripts/check_opportunity_management.py --manifest-dir path/to/metadata. Review all flagged issues before deploying.Run through these before marking work in this area complete:
Non-obvious platform behaviors that cause real production problems:
Deleting a Stage value corrupts active records silently — When a Stage picklist value is deleted while Opportunity records still use it, Salesforce does not block the deletion and does not reassign those records. The Stage field on affected records becomes blank, breaking forecast rollups and any validation rules that reference StageName. Always use the "Replace" action to move records to a new stage before deleting, or deactivate the value instead.
ForecastCategoryName values are platform-fixed and cannot be renamed — The five values (Pipeline, Best Case, Commit, Closed, Omitted) are hardcoded in the platform. Attempts to rename them via picklist metadata or the UI will fail silently or error. Org-specific category labels must be communicated through field help text, Path guidance, or documentation — not by renaming the platform values.
Splits cannot be disabled once any split record exists — Opportunity Splits is a one-way door. Once enabled and any split data is saved, the feature cannot be turned off. This also means the split type configuration (revenue vs. overlay) becomes permanent for the types that have data. Evaluate the business requirement thoroughly before enabling in production.
Team Selling must be enabled before Opportunity Splits — The platform dependency is hard. Attempting to enable Splits without Team Selling enabled first results in an error. The reverse (disabling Team Selling after Splits is on) is also blocked once split data exists.
Path enforces nothing — A common misconception is that configuring Path on a stage makes that stage required or orderly. Path is a visual guidance layer only. Reps can save a record at any stage regardless of Path configuration. Stage progression enforcement requires validation rules.
| Artifact | Description |
|---|---|
| Stage audit report | Table of all Stage values with their IsClosed, IsWon, Probability, and ForecastCategoryName values — used to verify correct forecast rollup mapping |
| Sales Process assignment matrix | Map of each Record Type to its assigned Sales Process and the stages that process exposes — used to confirm no stages are missing per motion |
| Checker output | Output of check_opportunity_management.py listing metadata issues found in the deployed manifest |