Business Process Changes in an Orchestration Plan

Choose How to Model a New or Replacement Business Process

When a pattern above introduces a new or replacement business process, decide whether to model it as a step group or a step. Your choice determines how easily you can change it again later.

As a fulfillment step definition group

Model a business process that runs entirely within Salesforce as a fulfillment step definition group, also called a step group. The step group holds the ordered steps of the process. A larger business process doesn't have to map to a single step group—multiple step groups can each represent a fragment of it. For more on defining step groups and steps in an orchestration plan, see Define Orchestration Plan Components.

As a step

Model a business process that calls a downstream or external fulfillment system as a single step within a step group, such as a callout step.

A fulfillment scenario links products to the step groups that run for an order. Group steps by lifecycle stage from the start—identify the steps that are common across products first, then split only the product-specific logic into separate step groups, and apply conditions at the scenario level when possible. This structure makes it easier to add logic paths later without refactoring.

Maintain Multiple Configurations of a Business Process

A rollout phase often means that more than one configuration of the same business process must coexist for some period. Choose the coexistence model that fits how long the old and new configurations need to run together.

Coexist for the long term

Keep the parallel scenarios in place indefinitely, routed by durable conditions. Use this model when the business intends to keep both variants, for example, for different products or regions.

Coexist until orders on the old configuration complete

Suppress the old configuration for new orders with a condition and let running orders age out on it. After all orders that reference the old configuration complete, retire the old step group, steps, or scenario. Dynamic Revenue Orchestrator blocks this deletion while incomplete steps still reference the step group, steps, or scenario—don't force a metadata override to bypass the block, since it risks corrupting in-flight orders. Periodically check for suppressed steps and retired scenarios whose orders have all completed, and remove them. Plans with many conditions add processing latency and can approach platform limits, especially for high-scale orders. For specific limits, see Dynamic Revenue Orchestrator Limits.

New configuration overrides the old after a cutoff

Use a date-based condition so that orders before the cutoff use the old configuration, and orders on or after the cutoff use the new one. This model gives a clean, time-based transition with no mixing of logic.

When to Use Code for an Orchestration Change

You can handle most orchestration plan changes using a configuration—modifying scenarios, step definitions, conditions, and step dependencies—rather than custom code. Configuration changes are safer to deploy across a phased rollout because you can control them with conditions and run them in parallel with existing logic. Use custom code, such as Apex or Flow, only when the change requires logic that conditions can't express.

Modifying underlying logic, such as Apex or Flow, while keeping the same step definition is safe only if the input and output contract stays identical. Any change to parameters or required payload properties can cause a running step to fail.

Impact of Entity-Level Changes by Order State

The patterns and coexistence models above work by editing one or more of four entities—fulfillment scenarios, step definitions, conditions, and step dependencies. This table lists the full effect of each entity-level change on new, running, and supplemental orders, so you can check the outcome for the specific change you're making.