Orders captured in Salesforce Commerce Cloud but not yet flowed to Marketing Cloud, Service Cloud, or the OMS after 24 hours. Sync drift turns into revenue and customer-experience gaps fast.
At a glance
A live count of Salesforce Commerce Cloud (SFCC, formerly Demandware) orders that were placed more than 24 hours ago but have still not propagated to a downstream system, typically the Order Management System (OMS), Marketing Cloud, or Service Cloud. In a healthy realm this number sits at zero or near it, because order export jobs and integrations run on a tight cadence. A persistent positive number means an integration is stalled, and every stalled order is a fulfilment, marketing, or support gap waiting to surface.
| What it counts | The number of SFCC orders confirmed more than 24 hours ago that have not yet been acknowledged as received by their downstream destination (OMS / Marketing Cloud / Service Cloud), based on the sync state Vortex IQ observes. |
| Why it matters | An order that never reaches the OMS does not get fulfilled. One that never reaches Marketing Cloud misses its confirmation and post-purchase journey. One that never reaches Service Cloud leaves agents blind when the customer calls. Sync drift is silent until a customer complains, this card makes it loud and early. |
| Reading the value | Zero is the target. A small steady number can indicate a slow but functioning queue; a number that climbs hour over hour is a broken or backed-up integration. Pair the trend with the failure-rate card to tell “slow” from “dead”. |
| Why 24 hours | SFCC order export and downstream sync normally complete in minutes. The 24-hour cutoff filters out normal in-flight orders and isolates genuinely stuck ones, removing noise from the brief, expected propagation delay. |
| Downstream systems | The usual destinations are the OMS (fulfilment), Marketing Cloud (transactional and lifecycle email), and Service Cloud (agent visibility). The exact set depends on which LINK cartridges and integrations the realm runs. |
| Common root causes | An OCAPI integration hit version EOL, an export job failed silently, a downstream system is rejecting payloads, or a queue is throttled. The failure-rate and version-status cards help pinpoint which. |
| Unit | number (count of orders) |
| Time window | Real-time (RT), the current backlog as of now |
| Alert trigger | >0, surfaced via sentiment_key: scc_downstream_sync_drift |
| Sentiment key | scc_downstream_sync_drift |
| Roles | owner, engineering, 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
An enterprise retailer on a single SFCC B2C realm. Orders flow from SFCC to a third-party OMS for fulfilment, to Marketing Cloud for confirmation email, and to Service Cloud for agent visibility. Snapshot taken at 09:00 on 12 Mar 26.| Downstream system | Orders synced (last 24h) | Orders awaiting sync >24h | State |
|---|---|---|---|
| OMS (fulfilment) | 18,940 | 312 | Stalled queue |
| Marketing Cloud (email) | 19,210 | 42 | Slow but moving |
| Service Cloud (agents) | 19,252 | 0 | Healthy |
| Orders Awaiting Downstream Sync >24h (card) | 354 | Alerting |
- 354 orders breaching 24 hours is a paging event, and the OMS is the culprit. With 312 of the 354 stuck on the OMS path, this is not a broad outage, it is one integration. Those 312 orders are paid for but not being fulfilled. Customers will start chasing shipments within a day, and the support queue will spike shortly after.
- Marketing Cloud’s 42 is a different problem class. It is small and likely a slow-draining queue rather than a dead one. The risk there is missed order-confirmation and post-purchase emails, a customer-experience hit, not a fulfilment one. Worth watching, but the OMS is the fire.
- Service Cloud at zero is the control group. It proves the order data itself is fine and the SFCC side is healthy, the problem is specifically the OMS export. That isolation is the whole point of splitting downstream state. Cross-reference API Version Status to check whether the OMS connector just hit a version EOL.
- The fix is operational, not just technical. Even after the OMS integration is restored and the 312 drain, someone needs to confirm those orders fulfilled within SLA and decide whether to proactively email affected customers. The card tells you the size of the cleanup, not just that one exists.
Sibling cards merchants should reference together
| Card | Why pair it with Orders Awaiting Downstream Sync >24h |
|---|---|
| Order Processing Backlog | The upstream sibling. Sync drift often shows up first as a processing backlog inside SFCC before it becomes a downstream gap. |
| Failed Orders (24h) | Distinguishes “order failed” from “order fine but not synced”. A spike in both at once points to a single broken integration. |
| API Version Status (OCAPI / SCAPI) | The most common cause of sudden sync drift is an integration hitting version EOL. Check here first when this card spikes. |
| OCAPI / SCAPI Failure Rate Spike or Version EOL Imminent | Tells you whether the stalled sync is caused by API calls actively erroring. |
| Orders Email Attribution | If orders never reach Marketing Cloud, attribution and post-purchase journeys break, this card shows the marketing-side blast radius. |
| Revenue at Risk (live) | Puts a money figure on the unfulfilled, unsynced orders sitting in the backlog. |
Reconciling against Salesforce Commerce Cloud
Where to look in Business Manager: SFCC’s admin tool is Business Manager, at a per-realm URL likehttps://<realm>.business.demandware.net. Sync state is not a single report, it lives across two areas:
- Administration, Operations, Job History (or Administration, Operations, Jobs): the order export and downstream sync jobs run here. A failed, skipped, or long-running job is the usual root cause of drift. Check the last run status and any error count.
- Merchant Tools, Ordering, Orders: open an individual order and inspect its export status flags. SFCC tracks whether an order has been exported / confirmed downstream; an order placed over 24 hours ago that still shows un-exported is exactly what this card counts.
| Reason | Direction of divergence |
|---|---|
| Acknowledgement vs export. Business Manager may mark an order “exported” once SFCC sends it; this card waits for downstream acknowledgement. An order can be “sent but not received”. | Card higher than BM exported-flag count |
| Multiple downstream destinations. An order can be synced to one system and not another; the card counts an order as awaiting if any tracked destination is missing it. | Card higher than any single-system view |
| Job History granularity. Job History shows batch-level success/failure, not per-order; a partially-failed batch can hide individual stuck orders. | Card more precise than batch counts |
| Timezone at the 24h boundary. Business Manager order timestamps render in site-local time; the card computes the 24h cutoff in UTC. | ±1 small set of orders at the boundary |
Known limitations / merchant FAQs
What does “downstream” actually mean for my realm? The set of systems your SFCC orders are supposed to flow into after capture. For most enterprise realms that is the OMS (for fulfilment), Marketing Cloud (for transactional and lifecycle email), and Service Cloud (for agent visibility), wired up via LINK cartridges or custom integrations. The card tracks whichever destinations are configured. Why 24 hours? Some of my orders sync in seconds. Exactly, which is why a healthy realm syncs almost everything well inside the window. The 24-hour cutoff exists to ignore normal in-flight orders and surface only the genuinely stuck ones. Lowering the threshold would flood the card with orders that are about to sync anyway. The card says 354 but my OMS team says they received everything. Who is right? Usually a handshake mismatch. SFCC may have sent the orders, but the card waits for downstream acknowledgement. If the OMS received them but never sent the acknowledgement back, the card still counts them. Check the acknowledgement leg of the integration, that is where “sent but not confirmed” hides. Does a high count mean orders are lost? Not lost, stuck. The orders exist intact in SFCC; they simply have not propagated yet. Once the integration is restored they normally drain through. The risk is the time spent stuck: unfulfilled shipments, missing confirmation emails, blind support agents. Speed of resolution is what limits the damage. What is the single most common cause of a sudden spike? An integration hitting an OCAPI version EOL. SFCC EOLs are hard cutoffs, so an export job that worked yesterday can stop dead today. Whenever this card spikes, check API Version Status first. Other causes include a downstream system rejecting payloads, a throttled queue, or a failed scheduled job. Is this real-time? Yes. It reflects the current backlog as of now, recomputing the 24-hour boundary continuously. There is no period selector, the time window isRT.
How do I clear a backlog once the integration is fixed?
Most SFCC order export jobs support a re-run or replay that picks up un-exported orders. Trigger that, watch the count drain in this card, then reconcile against the downstream system’s inbound log to confirm nothing was dropped. Finally, decide whether affected customers need a proactive update.