Share of orders by shipping status. The operations team’s read on how cleanly orders are getting out the door.
At a glance
A donut breakdown of Salesforce Commerce Cloud (SFCC, formerly Demandware) orders by shipping status, not shipped, part shipped, shipped, over the period, pooled across every site in the realm. SFCC tracks fulfilment on each order through its shipping objects and a shipping status, and this card rolls those into a share view. It is the operations team’s read on how cleanly orders are moving from confirmed to out-the-door, and a fast way to spot a fulfilment or warehouse stall.
| What it counts | The share of orders in each shipping status over the window: typically not shipped (confirmed, awaiting dispatch), part shipped (some shipments dispatched, some pending, common on split or multi-warehouse orders), and shipped (fully dispatched). Pooled across every siteId and locale. SFCC derives these from each order’s shipping objects and their shipment / fulfilment state. |
| Why it matters | The mix is the operational pulse for fulfilment. A healthy realm is dominated by shipped, with a steady not-shipped slice representing the normal in-flight pipeline. A growing not-shipped slice with flat order volume is the signature of a warehouse or downstream stall; a growing part-shipped slice can mean a stock or split-shipment problem on specific SKUs. |
| Reading the value | A donut by share. There is no single “good” number, the shape is what matters, and a shift in shape period over period is the signal. Read it alongside Pending Orders (created/new/open) and Order Processing Backlog when not-shipped grows. |
| Where the statuses come from | SFCC orders carry one or more shipping objects, each representing a shipment to an address with a delivery method. Their aggregate fulfilment state (nothing dispatched, some dispatched, all dispatched) rolls up into the order’s shipping status. Split shipments and multi-warehouse fulfilment produce the part-shipped state. |
| Not shipped vs backlog | A normal in-flight pipeline always shows a not-shipped slice, that is healthy. The concern is the slice growing while order volume stays flat, which means the dispatch drain has slowed. That is the same signal the Order Processing Backlog alert watches. |
| Currency | n/a, this is a share of order counts. The breakdown pools orders across every currency and locale on the realm. |
| Channels / sources | Multi-site by design. B2B trade orders (scheduled deliveries, longer fulfilment cycles, often part-shipped across releases) and DTC orders (fast single-shipment turn) pool together. Per-site filtering separates a B2B scheduling pattern from a DTC dispatch stall. |
| Unit | Number (rendered as share of orders) |
| Time window | 30D (trailing 30 days) |
| Alert trigger | none configured |
| Sentiment key | scc_shipping_status_breakdown |
| Roles | owner, operations |
Calculation
Calculated automatically from your Salesforce Commerce Cloud data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A Fortune-500 fashion retailer running on Salesforce Commerce Cloud B2C, four DTC sites and one B2B portal, fulfilling DTC from two regional warehouses and B2B from a dedicated trade DC. The 30-day window covers 14 Mar 26 to 12 Apr 26. Shipping statuses derived from order shipping objects, confirmed in Business Manager.| Shipping status | Orders | Share | Typical meaning |
|---|---|---|---|
| Shipped (fully dispatched) | 281,400 | 88.4% | All shipments out the door |
| Not shipped (awaiting dispatch) | 24,300 | 7.6% | Confirmed orders in the in-flight pipeline |
| Part shipped | 12,720 | 4.0% | Split / multi-warehouse orders, some shipments still pending |
| Realm-wide | 318,420 | 100% |
- The 7.6% not-shipped slice is the normal in-flight pipeline, until it grows. At any moment a healthy realm has orders confirmed but not yet dispatched, sitting inside the fulfilment SLA. The slice existing is fine. The signal is the slice growing while order volume stays flat, which means dispatch has slowed at a warehouse or a downstream export stalled. Read it together with Pending Orders (created/new/open): if both climb with flat orders, the drain has stopped.
- Part-shipped (4.0%) is mostly split and multi-warehouse orders. When a basket draws from two warehouses, or one line is in stock and another is on back-order, SFCC dispatches what it can and the order reads part-shipped until the rest follows. A brand fulfilling from multiple DCs always carries a structural part-shipped slice. A sudden jump points at a stock problem on specific SKUs, cross-check Low Stock Products and Out-of-Stock Products.
- B2B skews part-shipped and slow not-shipped, by design. Trade orders ship on scheduled releases against contractual lead times, so the B2B portal naturally carries a larger and slower-moving not-shipped and part-shipped share than DTC. Filter out the B2B
siteIdfor a clean read on DTC dispatch speed, which is the number that matters for customer-facing delivery promises. - No alert is configured on this card, and that is deliberate. The “right” shipping mix is contextual: it depends on warehouse count, split-shipment policy, and how much B2B scheduled volume the realm carries. A fixed threshold would fire constantly on a multi-DC realm. Operations reads the shape and its period-over-period drift, and leans on the Order Processing Backlog alert for the acute stall signal. Pair with Total Orders to read slices as absolute counts.
Sibling cards merchants should reference together
| Card | Why pair it with Shipping Status Distribution |
|---|---|
| Pending Orders (created/new/open) | The order-status view of the same pipeline. A growing not-shipped slice and a growing pending pool are two views of the same fulfilment stall. |
| Order Processing Backlog | The realm-wide alert for the acute version. When not-shipped blows out, the backlog alert is what tells the team to act. |
| Out-of-Stock Products | A rising part-shipped slice often traces to specific SKUs out of stock, holding the rest of a split order. Cross-check the OOS list. |
| Low Stock Products | The leading indicator. SKUs about to run out are the ones that will produce part-shipped orders next week. |
| Total Orders | The context. A growing not-shipped slice is healthy if orders grew with it, and a stall if orders are flat. |
| Cancellation Rate | Orders that cannot be fulfilled (no stock, no dispatch) eventually get cancelled. A stuck not-shipped slice often precedes a cancellation rise. |
Reconciling against Salesforce Commerce Cloud
Where to look in Business Manager: SFCC’s admin tool is Business Manager, reached at a per-realm URL likehttps://<realm>.business.demandware.net. To verify this card, go to Merchant Tools, Ordering, Order Search and use the shipping-status filters, or open individual orders and inspect their Shipments detail, which shows each shipping object, its line items, and its dispatch state. For a reporting view, Merchant Tools, Site, Reports & Dashboards, Operations breaks orders down by fulfilment state.
Other Business Manager views that look like the same number but aren’t:
- Order status (
OPEN,COMPLETED, etc.): the order lifecycle, a different axis from shipping status. An order can beOPENand not shipped, orCOMPLETEDand shipped. - Reports & Dashboards, Sales: revenue, not a fulfilment-state count.
- Carrier / 3PL tracking dashboards: the downstream view of in-transit parcels, useful for delivery SLA but on the carrier’s data, not SFCC’s shipping objects.
| Reason | Direction of divergence |
|---|---|
| Status taxonomy. SFCC’s raw shipping-status values vary by version and by how fulfilment integrations write back; this card groups them into not shipped / part shipped / shipped. A Business Manager raw-status read uses finer-grained values. | Grouping difference, not a true gap |
| Write-back timing. The shipped slice depends on when the OMS / WMS or carrier integration writes the dispatch back to SFCC. A lag in write-back makes the not-shipped slice read larger than reality. | Vortex IQ higher on not-shipped during write-back lag |
| Site filter scope. Business Manager defaults to the currently-selected site; Vortex IQ pools every site unless filtered. B2B scheduled volume skews the slower slices. | Direction depends on per-site mix |
| Split-shipment handling. How a multi-warehouse order is bucketed (part shipped vs not shipped vs shipped) depends on its individual shipping objects’ states. | Small, on the part-shipped slice |
| Time-zone. Business Manager uses the site’s configured time zone; Vortex IQ runs on UTC by default. | Boundary days shift |
| Export lag. SFCC’s Reports & Dashboards warehouse runs 5 to 30 minutes behind; SCAPI / OCAPI is near-real-time. | Report lags this card |
Known limitations / merchant FAQs
What shipping statuses does SFCC track and how are they grouped here? SFCC derives an order’s shipping status from its shipping objects and their dispatch state. The raw values vary by API version and by how fulfilment integrations write back, so this card groups them into three readable buckets: not shipped (nothing dispatched), part shipped (some dispatched), and shipped (all dispatched). Open an order’s Shipments detail in Business Manager to see the per-shipment state. Is a large not-shipped slice a problem? Not on its own. A healthy realm always has confirmed orders in the in-flight pipeline awaiting dispatch within the fulfilment SLA. The concern is the slice growing while order volume stays flat, which means dispatch has slowed at a warehouse or a downstream write-back stalled. Read it with Pending Orders (created/new/open) and lean on the Order Processing Backlog alert. Why do I have so many part-shipped orders? Almost always split and multi-warehouse fulfilment. When a basket draws from two DCs, or one line is in stock and another is back-ordered, SFCC dispatches what it can and the order reads part-shipped until the rest follows. A brand fulfilling from multiple warehouses carries a structural part-shipped slice. A sudden jump points at a stock problem on specific SKUs, cross-check Out-of-Stock Products. Why does B2B skew the distribution? B2B trade orders ship on scheduled releases against contractual lead times, so they sit not-shipped or part-shipped far longer than DTC by design. A realm with a B2B portal carries a structurally slower shipping mix. Filter out the B2BsiteId for a clean read on DTC dispatch speed, which is what drives customer-facing delivery promises.
Why is there no alert on this card?
Because the “right” shipping mix is contextual: it depends on warehouse count, split-shipment policy, and how much B2B scheduled volume the realm carries. A fixed threshold would fire constantly on a multi-DC realm. Operations reads the shape and its drift, and uses the Order Processing Backlog alert for the acute stall signal. You can add a per-card alert on the not-shipped slice if your fulfilment model makes that meaningful.
My number does not match Business Manager. Why?
Usually write-back timing or grouping. (1) Write-back lag, the shipped slice depends on when your OMS / WMS or carrier integration writes dispatch back to SFCC; a lag inflates the not-shipped slice. (2) Grouping, this card buckets raw statuses into three; a Business Manager raw read is finer-grained. (3) Site-scope, Business Manager defaults to one site, the card pools the realm. Confirm all three before treating a gap as an error.
Does this measure delivery, or just dispatch?
Dispatch. SFCC’s shipping status reflects whether shipments have left the warehouse, not whether the parcel has arrived. For in-transit and delivery SLA, reconcile against your carrier / 3PL tracking dashboards, which carry the downstream delivery events. This card is the right tool for “are we getting orders out the door”, not “have they arrived”.