A Complete Guide to Salesforce Order Orchestration

Orders are where revenue breaks quietly. The quote looks clean. The contract gets signed. Then the order hits fulfillment and things fall apart. Wrong items get billed. Invoices do not match what was sold. Fulfillment tasks stall without anyone noticing.

Gartner found that nearly 50% of B2B organizations lose 7% to 10% of annual revenue to leakage. A large share traces back to order and billing misalignment.

This guide covers how to design order orchestration in Salesforce that protects revenue from quote through invoice. For the full lifecycle context, see our Quote to Cash guide.

The Salesforce Order and Order Item data model

Every orchestration flow starts with the Order object. If you do not understand how Salesforce structures orders, you will build orchestration plans on a weak foundation.

The core objects

The Order object represents the customer’s commercial intent. It connects to Account, Contract, and Pricebook. Once activated, the Order is immutable. It does not change. All subsequent changes, cancellations, and amendments get handled through Change Orders, which are separate Order records.

Order Items carry line level detail. Product, quantity, unit price, billing behavior, delivery group, and term dates all live on the Order Item. These records come from approved quotes or contracts. They become the source of truth for fulfillment and invoicing. If an Order Item carries the wrong price or quantity, every invoice generated from it will be wrong.

Extended Revenue Cloud objects

Revenue Cloud adds objects that most teams underestimate until something breaks. 
  • Order Action records track every change event against an order. New orders, amendments, cancellations, and renewals each create Order Action records. These provide the audit trail that finance depends on.
  • Order Delivery Group defines how and where items get delivered. When a single order includes items going to different locations or on different timelines, Delivery Groups control the split.
  • Order Item Detail captures pricing and quantity breakdowns beyond the Order Item itself. Revenue Cloud generates these records to track quantity reductions during amendments, early renewals, derived pricing, and bundle reconfigurations.
  • Order Item Relationship maps parent child connections between order products. Bundled products use this to track which components belong to which bundle.
  • Order Item Attribute stores product attributes selected during configuration. Size, tier, region, deployment type. These values pass from the catalog through CPQ into the order and then into fulfillment.
The official Salesforce Transaction Management Order data model documents these objects and relationships. For a deeper look at how they connect to the full revenue lifecycle, see our Revenue Cloud data model guide.

The most common data model failure

The most frequent failure we see at RevSolutions is drift between Contract Line Items and Order Items. Pricing, quantities, or term dates do not carry forward cleanly from contract to order. Invoices never match. Finance spends weeks reconciling. And the root cause gets buried under layers of downstream fixes that never address the source.

Dynamic Revenue Orchestration

Dynamic Revenue Orchestrator, or DRO, is the native Salesforce Revenue Cloud engine that handles everything between order submission and order fulfillment. It bridges front office sales with back office operations. DRO has two core components: decomposition and orchestration.

Order decomposition

Decomposition breaks a commercial order into technical fulfillment tasks. The customer sees a single product. Fulfilling that product requires multiple systems to do multiple things.

Salesforce’s Trailhead documentation uses a clear example. A customer orders a laptop bundle with hardware, antivirus software, and a warranty. Fulfillment requires three separate actions: ship the laptop, activate the license, register the warranty. Decomposition handles this translation.

Salesforce uses Product Fulfillment Decomposition Rules to control how this works. You define a source product (what the customer sees) and a destination product (what the fulfillment system processes). Then you map fields and attributes between them.

Decomposition scope controls how products map into fulfillment line items. Salesforce supports four scopes.

→ Order Line Item (default): one to one mapping per line item.
→ Order: a single fulfillment line item for all products decomposing to the same destination.
→ Bundle: one fulfillment line item per bundle.
→ Account: a single fulfillment line item across orders from the same account.

The product catalog drives decomposition. If your catalog has incorrect product definitions or broken bundle structures, decomposition produces wrong results every time. Simple orders can skip decomposition entirely and go straight into orchestration.

Order orchestration

After decomposition produces fulfillment requests (sometimes called suborders), orchestration sequences and executes them. DRO generates orchestration plans dynamically, with fulfillment steps organized in swimlanes per fulfillment system: inventory, shipping, billing, provisioning. 
Steps within swimlanes depend on each other. A shipping step cannot execute until inventory check completes. A billing step cannot fire until delivery confirmation arrives. These dependencies enforce sequencing logic.

The orchestration plan provides a real time visual of every task. Each step shows its status with color coded indicators that update as the plan executes. Every team works from the same data inside Salesforce.

Designing orchestration plans

Orchestration plans live inside Fulfillment Workspaces. A workspace is the container for all fulfillment steps needed to deliver a specific product or product family.

Workspace structure

Inside each workspace, you create Fulfillment Step Definition Groups. These are logical groupings of related steps. A common pattern: one group for Procurement, one for Shipping, one for Billing, one for Provisioning. This maps directly to how your backend operations are organized. Within each group, you add Fulfillment Step Definitions. Each step definition has four key properties.

Step types and properties

  • Type. Salesforce supports five step types. Auto Task steps use Salesforce Flow to process internal data. Manual Task steps pause execution and wait for a human to complete an action like an approval. Callout steps communicate with external systems via JSON payloads. Milestone steps act as checkpoints that complete when all dependencies are met. Pause steps halt the plan until a specific condition becomes true.
  • Scope. Controls how many instances get created during execution. Plan scope creates one instance for the entire fulfillment plan. Bundle scope creates one per bundle. Line Item scope creates one per order line item.
  • Run As User. Assigns a user with the right permissions for callouts or record modifications.
  • Dependencies. Defines which steps must complete before a given step can start. Without correct dependencies, steps fire out of order and fulfillment breaks.

Linking plans to products

Fulfillment Scenarios link a product to a specific orchestration plan. When a customer orders Product X, Workspace Y triggers automatically. The Salesforce Fulfillment Orchestration data model documents every object involved.

SLA and jeopardy management

Every fulfillment step can have an estimated duration. If the step exceeds that duration, a jeopardy rule fires. Jeopardy rules trigger alerts, reassign tasks, or escalate to managers. Without SLAs, a failed callout to an external system can sit silently for days. Nobody notices until the customer complains or finance finds a gap during month end close.

Fallout management

When a step fails, fallout rules route failed tasks to manual queues where designated operators resolve them. Full automation is not realistic for every scenario. External system outages happen. API payloads fail validation. Fallout management gives you a controlled path for human intervention without breaking the overall plan. Salesforce’s Trailhead module on Orchestration Foundations covers this in detail.

Handling split orders

Split orders occur when a single customer order must be fulfilled from multiple locations, on different timelines, or through different systems. This is common in B2B where one order includes hardware from a warehouse, software from a provisioning system, and services from a scheduling platform.

How Salesforce handles splits

Salesforce controls splits through Order Delivery Groups and by generating multiple Fulfillment Orders from a single parent Order. Each Fulfillment Order gets its own fulfillment path with its own orchestration steps. All trace back to the same Order and the same Order Summary.
The Order Summary represents the current state of the order in a single view: fulfillment status, change orders, discounts, cancellations, returns, and refunds. While the original Order stays immutable, the Order Summary reflects what is actually happening across all splits.

The billing accuracy challenge

When an order splits into three Fulfillment Orders, each one must carry the correct pricing, tax calculation, and discount allocation from the parent Order Items. Poorly designed splits produce partial invoices, duplicate charges, or missed billing lines. These errors erode trust between sales, finance, and customers.

DRO’s decomposition scope settings directly control how splits are generated. Salesforce Order Management also provides flow core actions like Find Routes with Fewest Splits, which prioritizes fulfillment from locations that can ship the most items together.

Design best practice

Treat splits as a known pattern in your orchestration design, not as an edge case. Create dedicated step groups for multi location fulfillment. Add consolidated billing milestones that only fire after all split paths complete. Test split scenarios with sample orders before going live. If you skip this, splits will generate billing anomalies that surface weeks later during close.

Managing changes mid lifecycle

Mid lifecycle changes are the highest risk moment in order orchestration. A customer cancels one line item. Or upgrades to a higher tier. Or changes a delivery address after fulfillment has started. The orchestration plan must adapt without corrupting billing data.

Point of No Return

Salesforce uses a Point of No Return concept. The PONR marks the boundary after which an order cannot be amended in place. If a fulfillment step has passed the PONR, DRO communicates this back to CPQ, and a Change Order is required. If the step has not passed the PONR, the amendment can be submitted directly.

Change Orders

A Change Order in Salesforce is a separate Order record. It does not modify the original Order. It captures the change, whether that is a cancellation, return, quantity change, or upgrade, and updates the Order Summary. This preserves a full audit trail. Finance can always trace back to what was originally sold, what changed, and when.

Designing for mid lifecycle safety

Build orchestration plans with explicit Pause and Milestone steps at change sensitive points. Pause steps halt the plan until a condition is met, such as amendment approval. Milestone steps consolidate dependencies before moving forward.

Without these controls, mid flight changes create orphaned fulfillment tasks. A shipping step fires while a cancellation is processing. Billing generates an invoice for an item the customer just returned. These become support escalations, credit memos, and manual reconciliation.

For teams handling contract amendments that trigger order changes, the connection between contract and order must be clean. If the contract says one thing and the order says another, billing will split the difference in the worst possible way.

Common orchestration failures and how to prevent them

Every failure pattern we see at RevSolutions traces back to one of five root causes. None are exotic. All are preventable.

The five root causes

  • Order Items that drift from Contract Lines. Pricing, quantities, or term dates do not match. Usually caused by custom automation that modifies order fields during creation. Fix: add field level validation between Contract Line Item and Order Item at creation time.
  • Incorrect or missing decomposition rules. If a product lacks a decomposition rule, DRO does not know how to break it into tasks. The order stalls. Fix: audit decomposition rules every time a product launches or changes. Make it part of your launch checklist.
  • No fallout management configured. Teams build plans with auto tasks and callouts but never configure what happens when a step fails. Orders get stuck silently. Fix: configure fallout rules and manual queues for every callout and every auto task that depends on external data.
  • SLA thresholds not set. Without SLAs, no alerting for stuck steps. A failed callout can sit unresolved for days. Fix: set estimated durations and jeopardy rules for every step type. Start conservative and tighten.
  • Split orders that fragment billing. Each split path triggers billing independently without a consolidation milestone. Fix: add billing milestones that depend on all upstream fulfillment steps completing before any invoice is generated.

Operational monitoring

Set up dashboards that track fulfillment step completion rates, average SLA adherence, fallout queue volume, and order to invoice cycle time. Review weekly. When a metric drifts, investigate immediately. Small deviations compound fast. The companies that run clean orchestration treat it like a production system.

How this fits into the broader Quote to Cash lifecycle

Order orchestration does not exist in isolation. It sits between contract execution and billing. The accuracy of everything upstream determines whether orchestration receives clean inputs. The reliability of orchestration determines whether billing receives clean outputs.

The sequence matters.
→ Clean product catalog with correct selling models, attributes, and bundle structures.
→ Correct decomposition rules that map commercial products to technical fulfillment tasks.
→ Well designed orchestration plans with proper step types, scopes, dependencies, and fallout handling.
→ Split order handling with consolidated billing milestones.
→ Mid lifecycle controls with PONR, pause steps, and change order support.


Each layer depends on the one before it. If the catalog is wrong, decomposition produces wrong results. If decomposition is wrong, orchestration fires wrong tasks. If orchestration is wrong, billing generates wrong invoices. Revenue leakage does not start at the invoice. It starts at the catalog and accumulates through every handoff.

For the full lifecycle, start with our Quote to Cash guide.

What to do next

If you are building order orchestration for the first time, start with the data model. Map every object from Order through Fulfillment Order through Invoice. Confirm that your Order Items match your Contract Lines one to one. Then build decomposition rules and test them with sample orders before configuring orchestration plans.


If you already have orchestration running and see fulfillment failures or billing mismatches, audit your decomposition rules and fallout configuration first. These two areas account for the majority of production issues we see across RevSolutions engagements.

If you are evaluating DRO versus custom orchestration logic, the decision comes down to maintainability. Custom Apex works for simple scenarios. As product complexity grows and multi system fulfillment becomes the norm, DRO provides a structured, visual, and auditable approach that custom code cannot match at scale.

At RevSolutions, we help companies design order orchestration that connects cleanly to quoting, contracts, billing, and renewals. If you are planning a Revenue Cloud rollout or fixing an existing implementation, we can run a review focused on your specific order lifecycle.

You May Also Like…

0 Comments