Live count of orders awaiting fulfilment. The operations team’s running queue depth.
At a glance
A real-time count of Salesforce Commerce Cloud (SFCC, formerly Demandware) orders sitting inCREATED,NEW, orOPENstatus, the orders that have been placed but not yet fulfilled. This is the operations team’s queue depth. A healthy realm holds a steady pending pool that drains as the warehouse and downstream OMS work through it; a climbing pool means orders are arriving faster than they are being processed, or something downstream has stalled.
| What it counts | COUNT(orders WHERE status IN [CREATED, NEW, OPEN]) right now, pooled across every siteId and locale in the realm. These are SFCC’s pre-fulfilment statuses: an order that has been placed but not yet shipped, completed, cancelled, or failed. |
| Why it matters | Pending is the operational pulse. A stable pool is normal, orders flow in and drain out. A rising pool means one of two things: demand outran capacity (a sale, a campaign, a peak day), or the drain stopped (an OMS / WMS sync failure, a paused export job, a downstream outage). The card is a hero because a stalled drain is silent, revenue keeps booking while nothing ships. |
| Reading the value | A single live KPI number. Read it against the realm’s own normal baseline and the time of day / week, not an absolute target. The rate of change matters more than the level. |
| The three statuses | CREATED is a freshly placed order before payment confirmation; NEW and OPEN are confirmed orders awaiting fulfilment. A pool weighted toward CREATED points at a payment / confirmation problem; a pool weighted toward OPEN points at a fulfilment / downstream problem. |
| Healthy vs stalled | A healthy pending pool turns over: orders enter and leave within the merchant’s normal fulfilment SLA. A stalled pool grows without draining, that is the signal the Order Processing Backlog alert watches for. |
| Currency | n/a, this is an order count. Pending orders pool across every currency and locale on the realm. |
| Channels / sources | Multi-site by design. B2B trade orders (scheduled, often longer fulfilment cycles) and DTC orders (fast turn) pool together. Per-site filtering separates a B2B scheduling pattern from a DTC fulfilment stall. |
| Unit | Number |
| Time window | RT (real-time, live snapshot) |
| Alert trigger | >2x 30D avg, driven by sentiment_key: scc_pending_orders |
| Sentiment key | scc_pending_orders |
| 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 through a downstream OMS that pulls confirmed orders from SFCC via a scheduled OCAPI export. The snapshot is taken live at 12 Apr 26 09:00 UTC. The realm’s normal 30-day average pending pool is about 2,400 orders.siteId | Site / locale | CREATED | NEW / OPEN | Pending total | Normal baseline |
|---|---|---|---|---|---|
RefArch-US | US DTC, en_US | 210 | 2,940 | 3,150 | ~1,300 |
RefArch-UK | UK DTC, en_GB | 70 | 880 | 950 | ~520 |
RefArch-DE | DE DTC, de_DE | 50 | 610 | 660 | ~360 |
RefArch-JP | JP DTC, ja_JP | 40 | 290 | 330 | ~180 |
RefArch-B2B | B2B trade portal | 5 | 80 | 85 | ~90 |
| Realm-wide | 375 | 4,800 | 5,175 | ~2,450 |
- The pool (5,175) is 2.1x the 30-day baseline (~2,450), so the
>2x 30D avgalert fires. The realm-wide jump is real, but the shape tells you what kind of problem it is. The pool is overwhelmingly weighted towardNEW/OPEN(4,800) rather thanCREATED(375), which means orders are getting paid and confirmed, they just are not getting fulfilled. That points downstream, at the OMS export or the warehouse, not at checkout. - The next move is to check the drain, not the inflow. A confirmed-but-unfulfilled pile usually means the scheduled OCAPI export to the OMS stalled, the WMS stopped acknowledging, or a downstream integration is down. See Order Processing Backlog, which is the realm-wide alert for exactly this. If instead the pool were weighted toward
CREATED, the diagnosis flips to a payment / confirmation problem, check Failed Orders (24h) and Payment Status Distribution. - B2B is the only site at baseline. The B2B portal (85 vs ~90 normal) is flat, while every DTC site is roughly 2x. That rules out a B2B-only workflow problem and confirms the stall is on the DTC fulfilment path. Per-site reads are what separate a realm-wide drain failure from a single-site issue.
- A pending spike is not automatically bad, context decides. If a flash sale or a marketing campaign just ran, a 2x pool is the expected, healthy consequence of demand, and the right response is capacity, not panic. The alert is a prompt to look, not a verdict. Pair this card with Total Orders: if orders are up 2x, a 2x pending pool is draining normally; if orders are flat and pending is up 2x, the drain has stalled.
Sibling cards merchants should reference together
| Card | Why pair it with Pending Orders |
|---|---|
| Order Processing Backlog | The realm-wide alert that fires on the same signal. Pending Orders is the live number; the backlog alert is what tells the team to act. Same root signal, different surface. |
| Failed Orders (24h) | If the pending pool is weighted toward CREATED, the cause is at payment. Failed orders and stuck-pending orders are the two outcomes of a checkout / gateway problem. |
| Total Orders | The context. A 2x pending pool with 2x order volume is healthy demand; a 2x pending pool with flat orders is a stalled drain. |
| Cancellation Rate | Unpaid CREATED orders that never get paid eventually convert to cancellations. A climbing pending pool often precedes a cancellation rise. |
| Payment Status Distribution | If pending is rising because orders are stuck unpaid, the not-paid share moves with it. Read together to confirm a payment root cause. |
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, filter Status to New, Open, and Created (run them and sum, or use a saved multi-status search), with no date restriction, since pending is a live state not a date-bounded window. For a status breakdown, Merchant Tools, Site, Reports & Dashboards, Operations shows the live distribution of orders by status.
Other Business Manager views that look like the same number but aren’t:
- Order Search filtered to
COMPLETED: already-fulfilled orders, the opposite of pending. - Order Search filtered to
CANCELLED/FAILED: terminal-state orders, not in the pending pool. - Reports & Dashboards, Sales: revenue, not a queue-depth count, and it includes statuses outside the pending set.
| Reason | Direction of divergence |
|---|---|
| Snapshot timing. This card is a live snapshot; Business Manager Order Search is read on demand. A busy realm processes orders continuously, so the two reads taken seconds apart can differ. | Either, transient |
Status set. This card pools CREATED, NEW, and OPEN. If a Business Manager search omits one of the three, the counts will not match. | Business Manager lower if a status is omitted |
| Site filter scope. Business Manager defaults to the currently-selected site; Vortex IQ pools every site unless filtered. | Vortex IQ higher than a per-site view |
| Custom status mapping. Realms with custom pre-fulfilment statuses may hold pending orders under a non-standard status this card does not pool by default. | Vortex IQ may read lower until mapped |
| Time-zone. Not usually relevant for a live count, but a date-bounded Business Manager search uses site-local time while the card uses UTC. | Boundary only, if a date filter is applied |
| Export lag. SFCC’s Reports & Dashboards warehouse runs 5 to 30 minutes behind; if you reconcile against a report rather than live Order Search, expect lag. | Report lags this card |
Known limitations / merchant FAQs
What is the difference betweenCREATED, NEW, and OPEN?
They are SFCC’s pre-fulfilment statuses. CREATED is a freshly placed order before payment is confirmed; NEW and OPEN are confirmed orders awaiting fulfilment. This card pools all three because together they are the “not yet shipped, not yet terminal” queue. The split inside the pool is diagnostic: a pile of CREATED points at payment / confirmation, a pile of OPEN points at fulfilment / downstream.
Is a rising pending pool always a problem?
No. A flash sale, a marketing campaign, or a peak shopping day legitimately fills the pool faster than it drains, and that is healthy demand, not a fault. The alert is a prompt to look. The test is the drain: if order volume rose with the pool, it is draining normally; if orders are flat and pending is up, the drain has stalled. Pair with Total Orders.
My pending pool spiked but order volume is flat. What does that mean?
The drain stopped. Orders are arriving at the normal rate but not leaving the pending state, which almost always means a downstream stall: a paused or failed scheduled export to your OMS, a WMS that stopped acknowledging, or a downstream integration outage. This is exactly the signal the Order Processing Backlog alert watches.
The pool is weighted toward CREATED, not OPEN. Why does that matter?
A CREATED-heavy pool means orders are not getting paid and confirmed, which is a payment or checkout problem, not a fulfilment one. Check Failed Orders (24h) and Payment Status Distribution. An OPEN-heavy pool means orders are confirmed but not shipping, which is a fulfilment or downstream problem.
Does this include B2B orders?
Yes. B2B and DTC share the same Order object and statuses. B2B orders often sit in the pending pool longer by design (scheduled deliveries, contractual lead times), so a B2B-heavy realm carries a structurally larger and slower-turning pool. Filter out the B2B siteId for a DTC-only view of fulfilment speed.
Why does my number differ from a Business Manager Order Search?
Usually one of three reasons. (1) Status set, this card pools CREATED + NEW + OPEN; a Business Manager search that omits one will read lower. (2) Site-scope, Business Manager defaults to one site, the card pools the realm. (3) Snapshot timing, on a busy realm the live count moves continuously, so two reads seconds apart can differ. Custom pre-fulfilment statuses can also cause a gap until they are mapped.
How do I know what a “normal” pending level is for my realm?
Read it against the card’s own 30-day average, which is what the >2x 30D avg alert is anchored to, and against time of day and day of week. Pending naturally rises through the trading day and into peak periods. The alert deliberately uses a relative baseline rather than an absolute number, because a healthy pool size is entirely realm-specific.