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.
| What triggers it | The realm-wide pending pool, orders in CREATED / NEW / OPEN status awaiting fulfilment, crossing >2x the trailing 30-day average pending level. Measured live across every siteId and locale in the realm. |
| What it is | An alert card (alert_list), not a metric gauge. It surfaces the backlog condition and the affected scope so operations can act, rather than reporting a standing number. The underlying live count lives on Pending Orders (created/new/open). |
| Why it matters | A fulfilment stall is silent. Checkout keeps working, revenue keeps booking, customers keep getting confirmation emails, but nothing ships. Every hour a stall goes unnoticed adds orders to the pile and pushes delivery promises past SLA. This alert exists to make the silent failure loud. |
| What fires it in practice | (1) A stalled or paused scheduled export from SFCC to the downstream OMS / WMS. (2) A downstream integration outage (OMS, WMS, or 3PL not acknowledging). (3) A genuine demand spike (sale, campaign, peak day) outrunning warehouse capacity. (4) A payment / confirmation pile-up leaving orders stuck in CREATED. |
| What to do when it fires | First, check whether order volume rose with the pool, see Total Orders; if orders are flat, the drain has stalled. Then check the status split on Pending Orders (created/new/open): a CREATED-heavy pool points at payment, an OPEN-heavy pool points at fulfilment / downstream. |
| Scope | Realm-wide, multi-site. A downstream export or OMS failure usually hits every site at once; a single-site spike is more often demand or a site-specific stock issue. Per-site reads localise the blast radius. |
| Unit | Number (orders over the backlog threshold) |
| Time window | RT (real-time, evaluated live) |
| Alert trigger | >2x 30D avg pending, driven by sentiment_key: scc_alert_order_processing_backlog |
| Sentiment key | scc_alert_order_processing_backlog |
| 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 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.siteId | Site / locale | Pending now | Normal baseline | Over threshold? |
|---|---|---|---|---|
RefArch-US | US DTC, en_US | 3,150 | ~1,300 | yes |
RefArch-UK | UK DTC, en_GB | 950 | ~520 | yes |
RefArch-DE | DE DTC, de_DE | 660 | ~360 | yes |
RefArch-JP | JP DTC, ja_JP | 330 | ~180 | yes |
RefArch-B2B | B2B trade portal | 85 | ~90 | no (at baseline) |
| Realm-wide | 5,175 | ~2,450 | ALERT (2.1x) |
- 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
| Card | Why pair it with Order Processing Backlog |
|---|---|
| Pending Orders (created/new/open) | The live number behind this alert. This card tells you the backlog crossed the line; that card shows the standing pool and its status split. Always read together. |
| Failed Orders (24h) | A payment-gateway problem feeds a CREATED-heavy backlog. A failed-order spike often precedes this alert by a few hours when the failure mode is payment. |
| Total Orders | The first check when the alert fires. A 2x pool with 2x orders is healthy demand; a 2x pool with flat orders is a stalled drain. |
| Payment Status Distribution | If the backlog is CREATED-heavy, the not-paid share moves with it. Confirms a payment root cause. |
| Cancellation Rate | The downstream consequence. A backlog that is not cleared converts to cancellations as customers give up or clean-up jobs void stuck orders. |
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.
| Reason | Why |
|---|---|
Relative threshold. The alert fires at >2x the trailing 30-day average, not at a fixed count. A pool that looks unremarkable in absolute terms can still be 2x a quiet realm’s baseline. | The alert is anchored to the realm’s own normal, not a universal number. |
| Site filter scope. Business Manager defaults to the currently-selected site; the alert evaluates the whole realm. A backlog spread thin across five sites may not stand out on any single one. | Check the realm-wide status report, not one site. |
Status set. The backlog pools CREATED + NEW + OPEN. A Business Manager search that omits one status will understate the pile. | Include all three pre-fulfilment statuses. |
| Snapshot timing. The alert is evaluated live; a Business Manager read taken minutes later, after a drain catches up, can look calmer. | Compare reads taken close together. |
| Export lag. SFCC’s Reports & Dashboards warehouse runs 5 to 30 minutes behind; the alert uses near-real-time order state. | The report can lag the live condition the alert sees. |
| Custom status mapping. Realms with custom pre-fulfilment statuses may hold backlog orders under a non-standard status until it is mapped. | Confirm custom statuses are mapped into the pending set. |
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.