Alerts for Order Processing Backlog.
At a glance
A live alert that fires when the pool of unfulfilled Salesforce Commerce Cloud (SFCC, formerly Demandware) orders climbs well above its normal level, specifically when pending orders cross twice the trailing 30-day average. It is the operations team’s stall tripwire: a silent backlog is the dangerous one, because revenue keeps booking while nothing ships. When this alert is quiet, fulfilment is keeping pace; when it fires, orders are arriving faster than they are draining, or the drain has stopped.
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 every 15 minutes. The realm’s normal 30-day average pending pool is about 2,450 orders, so the backlog threshold sits at roughly 4,900. The alert is evaluated live; the snapshot below is 12 Apr 26 09:00 UTC.
Three things to notice:
- The realm-wide pool (5,175) is 2.1x the 30-day average (~2,450), so the alert fires. This is the same underlying number as Pending Orders (created/new/open); the difference is that this card converts the standing count into an actionable alert with affected-site scope. The job here is not to report the number, it is to make the team look now.
- Every DTC site is over threshold while B2B is flat, which localises the cause. The B2B portal fulfils from a separate DC on its own workflow and sits at baseline, so this is not a realm-wide infrastructure failure. The common factor across the elevated sites is the shared DTC fulfilment path, the scheduled OCAPI export to the OMS or the OMS itself. First action: confirm the export job is running and the OMS is acknowledging.
- The status split decides the diagnosis. On the Pending Orders card this pool is overwhelmingly
OPENrather thanCREATED, which means orders are paid and confirmed but not shipping, a downstream drain failure, not a checkout problem. If the pool had beenCREATED-heavy, the diagnosis would flip to payment, and the first checks would be Failed Orders (24h) and Payment Status Distribution. - A demand spike can fire this alert legitimately. If a flash sale had just doubled order volume, a 2.1x pending pool would be the healthy, expected consequence, and the right response is added fulfilment capacity, not an incident. That is why the very first check is order volume: a 2x pool with 2x orders is draining normally; a 2x pool with flat orders is a stall. The alert is a prompt to look, not a verdict.
Sibling cards merchants should reference together
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 the backlog condition behind this alert, go to Merchant Tools, Ordering, Order Search and filter Status to New, Open, and Created, then compare the live count against your realm’s normal level. Merchant Tools, Site, Reports & Dashboards, Operations shows the live distribution of orders by status, which is the fastest way to confirm a pile-up. To diagnose a stalled drain, check the export job in Administration, Operations, Jobs (job history and last-run status) and the downstream OMS / WMS integration logs.
Other Business Manager views that look relevant but aren’t the trigger:
- Order Search filtered to
COMPLETED: already-fulfilled orders, the opposite of the backlog. - Order Search filtered to
FAILED: hard payment failures, a separate signal, see Failed Orders (24h). - Reports & Dashboards, Sales: revenue, which keeps booking even while the backlog grows, exactly why the backlog is silent.
Known limitations / merchant FAQs
What exactly fires this alert? The realm-wide pending pool, orders inCREATED / NEW / OPEN, crossing twice its trailing 30-day average. It is a relative threshold, not a fixed count, so it adapts to your realm’s normal level. The standing number it watches lives on Pending Orders (created/new/open); this card turns that number into an actionable alert with affected-site scope.
The alert fired. What is the first thing I should check?
Order volume. Pull up Total Orders: if orders rose with the pool (a sale, a campaign, a peak day), the backlog is healthy demand draining normally and the answer is capacity, not an incident. If orders are flat and the pool is up 2x, the drain has stalled and you have a fulfilment or downstream problem to chase.
How do I tell a fulfilment stall from a payment stall?
Check the status split on Pending Orders (created/new/open). An OPEN-heavy pool means orders are paid and confirmed but not shipping, a fulfilment / downstream problem; check the scheduled export job and the OMS / WMS. A CREATED-heavy pool means orders are not getting paid, a payment problem; check Failed Orders (24h) and Payment Status Distribution.
Why is this an alert card rather than a number?
Because a fulfilment stall is silent: checkout works, revenue books, confirmation emails go out, and nothing ships. A standing gauge is easy to miss. An alert that fires on a relative threshold makes the silent failure loud and routes it to the operations team with the affected-site scope attached. The raw count is still available on the Pending Orders card.
Can a demand spike fire a false alarm?
It can fire the alert, but it is not a false alarm, it is the correct signal that demand has outrun current fulfilment capacity. The right response differs (add capacity rather than chase a broken integration), but you still want to know. The volume check (orders up with the pool, or flat) is what separates “scale up” from “something broke”.
Why does Business Manager sometimes look normal when the alert fired?
A few reasons. (1) Relative threshold, the alert fires at 2x your own baseline, which can look unremarkable in absolute terms. (2) Site-scope, Business Manager defaults to one site while the alert evaluates the whole realm, so a backlog spread across sites may not stand out anywhere. (3) Status set, the backlog pools all three pre-fulfilment statuses; a search that omits one understates the pile. (4) Snapshot timing, a read taken after the drain catches up looks calmer.
Does the B2B portal factor into the realm alert?
Yes, B2B pending orders are in the pooled count, but B2B naturally carries a slower-turning pool (scheduled deliveries, contractual lead times), so its baseline is built into the 30-day average. A B2B-only spike rarely fires the realm alert on its own. Filter to the B2B siteId if you want to watch the trade portal’s backlog separately.
What should be in my runbook when this alert fires?
A practical order. (1) Check order volume to rule demand in or out. (2) Read the CREATED vs OPEN split to point at payment or fulfilment. (3) If fulfilment: confirm the scheduled export job last-run status in Business Manager Jobs and the OMS / WMS acknowledgements. (4) If payment: check PSP credentials and the failed-order count. (5) Once cleared, watch the pool drain back below threshold and confirm delivery SLAs were not breached for the affected orders.