Picture an illustrative wholesale distributor with 2,400 orders a day, 5 warehouses and a customer service team that answers the same question all morning: where is my order? Agents open the CRM, find an order, then open the warehouse system, then the carrier site, then a spreadsheet of backorders that planners update by hand. When a payment fails at capture or a warehouse rejects a shipment, nobody sees it until the customer calls. The distributor doesn’t need another report. It needs a single record that tells the truth, and a queue that catches problems before customers do.
This article explains how a company can build order visibility and exception handling on Salesforce, using Salesforce’s own Order Management documentation and Trailhead material for the data model, statuses, flows and limits. It covers what the platform does and doesn’t do, how exceptions get captured and routed, what event volumes look like and what to check before you commit. Licensing, edition and pricing details change, so confirm them with Salesforce and your implementation partner before you budget.
TL;DR
- Order Management is the system of record for the order lifecycle, not for everything. Salesforce’s Trailhead material says it brings together capture, fulfillment, delivery and service in a central repository, but payments, shipping and other supply chain execution still need separate systems connected by apps or custom integrations. Decide what lives where before you design anything.
- Exceptions need a record, an owner and a rule. The implementation guide describes a Process Exception object with statuses from New and Triaged to Resolved, created by a flow that listens for an event. Define which failures create exceptions, who works them and what auto-resolves, then measure the queue weekly.
- Check limits and licenses early. Event allocations differ by edition, Order Management needs its own license and some features need Growth or Plus. Run a small proof of concept with realistic volumes before you commit, and keep the documentation page numbers with the project file.
What order visibility means, and what the platform covers
Visibility means a single trustworthy answer to “where is it?” Salesforce’s Order Management overview describes a global view of the full order lifecycle, with capture, fulfillment and delivery managed in a single place and service agents able to see order data and history alongside the customer record. For a distributor or manufacturer, the practical benefit is that customer service, sales and planners look at the same status instead of 3 different exports. The record is only as good as the feeds that update it.
The platform doesn’t execute everything. The same material says Order Management doesn’t, by itself, perform all the processes: payments, shipping and other supply chain functions need separate systems, connected through partner connector apps or custom integrations. That’s an important design boundary. Your warehouse management system, carrier integrations and payment gateway remain sources of truth for their own events, while Salesforce holds the order and its state and tells people what to do next.
The lifecycle has 4 stages in the documentation. Capture happens when the order is submitted and payment is authorized, fulfillment assigns the order to a location, delivery hands items to a carrier and captures payment, and service covers questions, cancellations, returns, refunds and reshipments. The overview is written around commerce scenarios, but it describes the B2B flow as similar. If your business runs on contracts and scheduled releases, you’ll also need to look at how agreements feed orders, which a later section covers.
The data model behind the status
- Order Summary holds the current state. Salesforce’s implementation guide says the Order Summary reflects the sum of the original order and any later changes, and that service users work with summaries rather than base order records. That distinction matters for reporting: build dashboards on summaries, because the original order doesn’t show cancellations or returns that came afterward. Ask report builders to confirm which object each dashboard tile reads from before launch.
- Order Product Summary tracks quantities by stage. It records ordered, canceled, allocated, fulfilled and returned quantities, and the guide says they update automatically from actions rather than direct edits. If your planners ask how many units of a line are allocated but not shipped, this object answers. Resist the urge to let users edit quantities by hand, because that breaks the audit trail the model creates. Lock those fields against edits.
- Fulfillment Order represents a shipment request to a location. It groups products sharing the same location, delivery method and recipient, and 1 order summary can have several. Shipments and shipment items link to a fulfillment order, and invoices tie to it as well. This is the object most operations teams watch, since a late or rejected fulfillment order is the usual start of an exception. Add the location to every list view.
- Change records capture why. The guide describes Order Product Summary Change records that store the type and reason for a return or cancellation, and change orders created only for changes that affect charges or payments. Reasons come from a picklist, so design it carefully. Vague reasons such as “other” make later analysis of root causes almost useless for planners. Review the reasons used every quarter and merge the ones that overlap.
- Process Exception records business problems. The guide gives payment capture failure as an example. The object has statuses that fall into Active, Inactive and Resolved categories, and standard platform events announce changes. Exceptions deserve their own section below, because they’re the part of the model that turns visibility into action. Plan how the object is surfaced to users, with list views by status and owner, because an exception nobody can find is the same as a record that doesn’t exist. Give each type a short description that tells the reader what to do.
Statuses, categories and what quantities do
Salesforce maps every status to a fixed category, and the guide says you can add statuses but you can’t change the categories. For a fulfillment order, Draft maps to Draft, Activated to Allocated, Fulfilling to Assigned and Pickpack, Closed to Fulfilled and Canceled to Canceled. That design lets reports and automations rely on categories while the business uses its own vocabulary. Add custom statuses sparingly, and document which category each belongs to, so a new status doesn’t quietly change how a report counts orders.
Status changes drive quantity changes. When a fulfillment order moves to Activated, allocated quantity rises and available-to-fulfill falls. When it moves to Closed, the allocated quantity moves to fulfilled and available-to-return. Canceling an order product reduces total and net ordered quantity and increases the canceled quantity, while a return order product reduces available-to-return and raises returned quantities. These rules are what make the numbers reconcile, which is why teams that bypass the standard actions with direct data loads often end up with quantities that don’t add up.
Pay attention to the integration points that change status. In the guide’s example workflow, an advance ship notice from the fulfillment provider either creates shipments and sets the fulfillment order to Fulfilled, or sets it to Canceled, and reaching Fulfilled can trigger invoice creation and payment calls. If your warehouse sends notices late or in the wrong sequence, statuses lag reality. Agree on the message formats and timing with the warehouse team, and include a rule for what happens when a message never arrives.
A reference table of fulfillment order behavior
| Fulfillment Order status | Category | Quantity effect | What the planner should watch |
| Draft | Draft | None yet | Orders stuck before allocation |
| Activated | Allocated | Allocated rises; available-to-fulfill falls | Allocation to the wrong location |
| Fulfilling | Assigned, Pickpack | Work in progress | Time in pick and pack beyond the target |
| Closed | Fulfilled | Allocated moves to fulfilled and available-to-return | Missing shipment or invoice |
| Canceled | Canceled | Allocated reduced; availability recalculated | Reason code and rerouting |
The table paraphrases the default statuses and category mappings in Salesforce’s implementation guide, so confirm them against the version your org runs. The right-hand column is a suggestion from this article, not from the documentation. The useful habit is to attach a time threshold to each status, such as “no fulfillment order should remain Activated for more than 4 hours without moving,” then build an exception rule that fires when the threshold passes. Statuses without time limits describe a snapshot, and thresholds turn them into alerts.
How exceptions get captured and worked
Start with the Process Exception object. Salesforce’s guide describes it as the record of a business problem, with statuses that group into Active (New, Triaged), Inactive (Ignored, Paused, Voided) and Resolved (Resolved). A flow named Create Process Exception triggers from a ProcessExceptionEvent, so any integration or automation that detects a problem can publish the event and let the platform create the record. The pattern separates detection from handling, which means a warehouse integration doesn’t need to know who works the queue.
Give every exception type an owner and a next step. A payment capture failure belongs to finance operations, an allocation failure to the planning team and a rejected shipment to the warehouse liaison. Create queues or assignment rules for each, define the target time to triage and write the expected action in plain language. When exceptions land in a shared inbox with no owner, they age. The metric to watch is the age of the oldest New exception, because it measures neglect more reliably than the total count.
Decide what resolves itself. Many exceptions are transient: a carrier API times out, a payment retries successfully, an inventory sync catches up. A rule that waits a set interval, rechecks and closes the record automatically as Resolved or Ignored saves human time. Be careful about silent suppression. Keep a count of auto-resolved exceptions by type and review it monthly, because a rising auto-resolve count can hide a failing integration that’s quietly retrying all day.
A taxonomy of exceptions worth catching
Start with the exceptions that cost money or customers. Payment failures at capture can block shipment and revenue. Allocation failures happen when no location has enough inventory or the routing rules can’t find a valid fulfillment path. Rejected or canceled fulfillment orders signal warehouse problems. Late shipments mean a fulfillment order has stayed in a status beyond its threshold. Address and delivery-method errors send items to the wrong place, and return or refund failures leave customers waiting for money.
Add a second group that affects planning rather than a single order. Backorders that cross a size threshold, a supplier delivery that slips, a sales agreement running well below its planned quantity or a customer whose orders have fallen suddenly are patterns across many records. Those belong in planner dashboards and alerts rather than in the individual exception queue. Mixing order-level and portfolio-level problems in a single queue buries the former under the latter, and each group needs a different owner.
Keep the first release small. A dozen well-defined exception types that people actually work beat 60 that nobody trusts. For each type, write its trigger, severity, owner, target triage time, expected resolution steps and whether it can auto-resolve. Review the list after 90 days, retiring types that never fire and adding those that staff handle informally in email. The exception catalog is a living document, and the most useful additions usually come from the questions customer service already gets asked.
Events, integration and the allocation question
- Platform events carry the signals. The implementation guide lists events including FOStatusChangedEvent, OrderSummaryCreatedEvent, OrderSumStatusChangedEvent and ProcessExceptionEvent. Flows and external systems can subscribe to them, which is how a status change in Salesforce can update a planner dashboard, notify a carrier integration or trigger a Slack message. Treat event names and payloads as an interface contract and version your changes. Keep a catalog of every subscriber, so a payload change never surprises a team.
- Change Data Capture publishes record changes. Salesforce documents default allocations of events delivered per rolling 24 hours, at 25,000 for Enterprise, 50,000 for Performance and Unlimited and 10,000 for Developer. It also documents concurrent client limits of 1,000, 2,000 and 20 respectively. Those numbers apply to the Change Data Capture documentation, and platform events have their own allocations, so check both against your design before you rely on them. Verify both before launch.
- Events are retained for 72 hours. The documentation says events received while a subscriber is disconnected are stored for 72 hours and can be retrieved with a replay ID. That gives an integration a window to recover after an outage, but it isn’t an archive. Design subscribers to track their last processed replay ID, handle duplicates safely and alert when they fall behind, since a weekend outage can exceed 72 hours.
- An add-on raises the ceiling. Salesforce documents an add-on that adds 100,000 events a day to the 24-hour allocation as a usage-based entitlement of 3 million a month, removes the limit on selected entities and is available only in production orgs. With the add-on, the 24-hour limit including a grace amount is 125,000 for Enterprise and 150,000 for Performance and Unlimited. Confirm current numbers and pricing with your account team.
- Throughput limits matter at peak. Trailhead states that Order Management can ingest up to 5,000 B2C Commerce orders per minute and process up to 2,500 per minute. A distributor with 2,400 orders a day is nowhere near that limit, but a flash sale or an end-of-quarter push can approach it. Load-test with your peak, not your average, and plan how the system queues work. Document the peak you tested and the date.
Event volume arithmetic
| Assumption (illustrative) | Value | Result |
| Orders per day | 3,000 | Baseline volume |
| Record changes per order that publish change events | 12 | 36,000 events a day |
| Enterprise default allocation | 25,000 per 24 hours | Demand is 144 percent of allocation |
| Enterprise with add-on, 24-hour limit | 125,000 | Demand is 28.8 percent of limit |
| Peak order ingest, flash sale | 20,000 orders in 1 hour, about 333 a minute | Well under the documented 5,000 a minute |
The inputs are mine. I assumed 12 record changes per order, such as the summary, its product lines, a fulfillment order, a few status updates and a shipment, and I assumed each change publishes an event to an external subscriber. Your design might subscribe to fewer objects, which lowers the count, or add custom objects that raise it. The point is to do this arithmetic before go-live, because an allocation shortfall appears as silently missing updates in downstream systems rather than as a loud error.
Reduce volume by design. Select only the entities you need, publish custom platform events for meaningful milestones instead of every field edit and avoid integrations that update the same record repeatedly. If your demand still exceeds the default, evaluate the add-on, or consider an integration pattern that batches changes. Ask your Salesforce account team to confirm which allocations apply to your edition and contract, and document the assumptions in your architecture file so the next architect doesn’t have to rediscover them.
Inventory, routing and the allocation flow
Order visibility is shallow if inventory is wrong. Salesforce’s guide covers location setup with a Location Type picklist, location groups that bundle locations and assignments that let 1 location belong to several groups. For Omnichannel Inventory, locations and groups it manages need a sync flag set. The practical decision is which system owns available-to-promise numbers: the warehouse system, an inventory service or Salesforce. Pick 1 owner, define the update frequency and show customer service the age of each number.
The guide also notes that allocation, the step that creates fulfillment orders and assigns them to locations, relies on a custom flow rather than an out-of-the-box flow. Sample packages demonstrate allocation, fulfillment, invoicing and payments with flows and Apex, but they aren’t compatible with every Commerce configuration. Plan time to design routing rules that reflect your business: nearest warehouse, cost, split shipments, customer priority, stock reservations and hazardous goods restrictions. Test rules with ugly cases, such as an order whose lines sit in different warehouses.
Track routing attempts. The Order Summary Routing Schedule object represents an attempt to route an order summary to 1 or more inventory locations, including future scheduled attempts and completed ones. That gives exception handling something concrete to examine when an order can’t be allocated: how many attempts occurred, when, and what happened. Build an alert on repeated failed attempts so planners see a backlog before customers ask, and include the order’s value and promised date in the alert to help prioritize.
Contract-driven demand in manufacturing
Sales agreements bring planned volume into view. Trailhead describes Manufacturing Cloud sales agreements as long-term supply agreements that give account teams visibility into committed and actual order volumes, tracked over time, with the ability to adjust planned quantities, prices and discounts. For a manufacturer selling on annual contracts, that shifts the question from “where is this order?” to “is this customer buying what they promised?” Both questions belong in the same operating view.
Variance is an exception too. When actual orders run well below the planned quantity, the sales and operations team needs to know before the quarter closes. Trailhead notes agreements help monitor customer compliance and can adjust prices and discounts when a customer buys less than planned. Define variance thresholds, such as a 15 percent shortfall against the plan for 2 consecutive periods, as an illustration, and route alerts to account managers and planners. Choose thresholds with sales leadership so the alerts match commercial reality.
Connect the contract to the order. The visibility gain comes when an order created against an agreement carries the reference, so reports can roll up actual volume by agreement, account and product. Check how your design links them, since the documentation reviewed here doesn’t describe the integration between agreements and Order Management in detail. Confirm in a proof of concept that orders, shipments and agreement actuals reconcile, and that returns and cancellations reduce the actual volume correctly.
What each role should see
- Customer service needs status and promises. A single page showing order summary, fulfillment orders, shipments, exceptions and customer history lets agents answer without switching tools. Include the promised and estimated dates, the last status change time and a plain explanation of any open exception. Agents shouldn’t need to understand object names, so label fields in business language and hide technical detail. Test the page with 5 real agents before you roll it out.
- Planners need queues and trends. They want the open exception count by type and age, the backlog by location, orders past their promised date and allocation failures. Add trend lines by week so a rising problem shows early. A planner’s dashboard should drive action: each tile should link to a filtered list of the exact records to work, not to a report that must be sliced by hand. Review the tiles monthly.
- Warehouse and logistics need work lists. Fulfillment orders waiting for pick, items assigned but not shipped, rejected notices and carrier exceptions belong in a view they can use during a shift. If the warehouse system remains their main tool, push exceptions to it or into a shared messaging channel so they don’t need a second login for routine work. Keep the list short enough that a picker can scan it in 10 seconds.
- Leaders need a short scorecard. Pick a small set of measures: on-time shipment rate, the share of orders with an exception, median time to triage, median time to resolve and the age of the oldest open item. Review them weekly. Each measure needs a definition written once, because arguments about how a metric is calculated can consume a meeting that should have been about the fix. Publish the definitions beside the chart.
Exception workload arithmetic
| Input (illustrative) | Value | Result |
| Orders per day | 2,400 | Baseline |
| Share of orders raising an exception | 4 percent | 96 exceptions a day |
| Manual handling time | 6 minutes each | 576 minutes, or 9.6 hours a day |
| Share auto-resolved by rules | 60 percent | 38.4 left for people |
| Remaining manual time | 6 minutes each | 230.4 minutes, or 3.84 hours a day |
Assuming a person handles 8 hours of work a day, the manual workload falls from 1.2 full-time equivalents to about 0.48 with the auto-resolve rule, saving roughly 5.8 hours a day. All inputs are invented. Real exception rates differ widely by industry, and some exceptions take hours rather than minutes. The exercise shows why measuring your own rate matters: a modest change in the exception percentage or the auto-resolve share moves staffing by a meaningful amount.
Use the arithmetic to set targets and staffing for the first 90 days. Start by logging manual exceptions for a month before automating, so you know the real mix. Automate the top 3 types by volume, track the auto-resolve share, and watch the manual queue age. If the rate of new exceptions climbs, treat it as a signal about upstream quality, such as address data or inventory accuracy, instead of hiring more people to absorb the symptom.
Prerequisites, licensing and setup gotchas
Licensing and permissions need attention up front. Salesforce’s guide says an Order Management license must be purchased and activated, that users need the System Administrator profile or the Standard Platform User profile plus the Order Management permission set license, and that each permission set with that license consumes a license per user. It also says Lightning Experience is required. Count your agents, planners and integration users before you quote the project, since a license shortfall surfaces late and expensively.
Some features depend on the implementation tier. The guide states that the return merchandise authorization capability is available only in Growth or Plus implementations. It also notes that person accounts are optional but can’t be turned back off once enabled, and that enabling them requires a support case that can take about 5 business days. Decisions like those are cheap to make in week 1 and costly to reverse in month 6, so list them in a design decision log.
Configuration choices can create conflicts. The guide advises not selecting the option to enable reduction orders, because it can conflict with Order Management change orders. It warns that adding a required custom field on Order requires updating the service flows, or they fail, and that flows can’t use localized labels, so multilingual teams need copies per language. Return reasons must match between the return line item and the change record. Test each of these in a sandbox before you build on them.
A phased rollout and the mistakes to avoid
Start with visibility, then add exceptions, then refine flows. In the first phase, load orders, fulfillment statuses and shipments into the standard objects, build the service console view and confirm the numbers reconcile with the source systems for a representative week. In the second, introduce a small exception catalog with queues, owners and thresholds. In the third, automate resolution, add planner dashboards and connect contract data. Each phase should end with a measurable result, such as a drop in where-is-my-order calls.
The most frequent mistake is building around the demo rather than the data. Clean test orders hide the real mess: partial shipments, substituted items, split orders, backorders and manual overrides. Run a pilot on a slice of real traffic, such as 1 product line or 1 warehouse, and keep the legacy process running in parallel until the numbers match. Document every mismatch and decide whether to fix the data, the integration or the process.
Other mistakes recur. Teams let users edit quantities directly, which breaks the audit trail. They create too many statuses without category mappings, so reports disagree. They treat exceptions as a reporting problem rather than a workflow with owners. They skip event volume math until the first peak. And they forget the change process: a new warehouse, carrier or payment gateway alters the feeds, so build a checklist that tests the exception rules whenever an integration changes.
Questions for an implementation partner
- Which parts of our supply chain stay outside Salesforce, and how will they connect? The documentation is clear that payments and shipping need other systems. Ask for an architecture diagram showing each system, each interface, the event or message that carries the data and the owner of every connection. A partner who can’t draw this on day 1 won’t build it correctly in month 4. Ask them to name the owner of each.
- Who owns inventory numbers and the allocation logic? Ask where available-to-promise is calculated, how often it refreshes and how the custom allocation flow handles split shipments and failed routing. Request test cases that include the awkward orders your team knows about. Confirm that the allocation design doesn’t depend on sample code that isn’t compatible with your commerce setup. Ask what happens when 2 sources disagree, and who breaks the tie on the day.
- How will you size events, licenses and limits? Ask for a written estimate of event volumes, the editions and add-ons assumed, the concurrent client counts and the number of Order Management licenses. Compare their assumptions with the published allocations, and ask what monitoring will warn you when usage approaches a limit. Have your Salesforce account team confirm the numbers in writing. Ask for the monitoring alert thresholds in writing, with names.
- How will we prove success? Agree on measures before work starts: reduction in status inquiries, on-time shipment rate, exception triage time and the age of the oldest open exception. Ask the partner to establish baselines from current data, to report weekly during the pilot and to hand over documentation and training so your own staff can maintain the exception rules after the project. Write the baselines into the statement of work.
FAQs
What’s Salesforce Order Management?
It’s a Salesforce product that brings the order lifecycle, from capture through fulfillment, delivery and service, into a central repository with a global view, according to Salesforce’s Trailhead material. It doesn’t replace payment, shipping or other supply chain systems, which connect through partner apps or custom integrations. It requires its own license and setup, so confirm editions and pricing with Salesforce. Ask for the current feature list before you scope the project.
How does Salesforce track order status?
The implementation guide describes an Order Summary that reflects the original order plus later changes, Order Product Summaries that track quantities by stage and Fulfillment Orders that represent shipment requests to locations. Statuses map to fixed categories such as Allocated and Fulfilled. Integrations such as advance ship notices update those statuses, so the quality of the feed determines the quality of the view. Test the feed timing in a sandbox.
How do exceptions work?
The guide describes a Process Exception object that records business problems such as payment capture failures, with statuses grouped as Active (New, Triaged), Inactive (Ignored, Paused, Voided) and Resolved. A flow creates the record when a ProcessExceptionEvent is published. You still need to define the exception types, owners, queues, target times and which exceptions resolve themselves. Treat the catalog as a living document and review it after the first 90 days.
Can Salesforce handle our order volume?
Trailhead states that Order Management can ingest up to 5,000 B2C Commerce orders per minute and process up to 2,500 per minute. Separate limits apply to events: Change Data Capture documentation lists 25,000 events per 24 hours for Enterprise by default, with an add-on that raises it. Do the arithmetic for your design, load-test at peak and confirm limits with Salesforce. Write the peak you tested into the project file.
Do we need a Manufacturing Cloud?
Not necessarily. Manufacturing Cloud adds sales agreements for committed versus actual volumes, which suits contract-driven manufacturers. Order Management covers the order lifecycle. Which you need depends on whether you sell on agreements, how you plan demand and what your other systems already do. The documentation reviewed here doesn’t detail how the 2 connect, so test that in a proof of concept. Ask your partner to demonstrate the link with your own sample data.
What are the common implementation pitfalls?
The guide warns about enabling reduction orders, which can conflict with change orders, about required custom Order fields that break service flows unless updated, about localization limits in flows and about person accounts being irreversible. Beyond those, the usual problems are unreliable feeds from warehouse systems, unclear inventory ownership, too many statuses and exceptions with no owner. A pilot with real data surfaces most of them. Record each decision in a log.
How long does it take to roll out?
It depends on integrations, data quality and the number of locations, and the documentation reviewed doesn’t give a timeline. A phased approach is safer: visibility first, then exceptions, then automation and planning dashboards. Ask your partner for dated milestones with measurable outcomes at the end of each phase, and keep the legacy process running in parallel until the numbers reconcile. Expect the data cleanup to take longer than the configuration itself.
What should we measure to know it’s working?
Track the volume of where-is-my-order contacts, on-time shipment rate, share of orders raising an exception, median time to triage, median time to resolve and the age of the oldest open exception. Establish baselines before launch from current data. Review the measures weekly, and investigate any rise in new exceptions as a signal about upstream data or process quality. Share the baselines with your partner before the project begins, so targets are realistic.
