Revenue at Risk (live), Salesforce Commerce Cloud

Revenue at Risk (live), the running total of revenue exposed by open issues across your realm. How to read it, why it matters, and how to act on it.

Metrics type: Key Metrics • Category: Ecommerce Platform

Revenue at Risk (live) for the selected period.

At a glance

A single live figure summing the revenue currently exposed by open, unresolved issues across your Salesforce Commerce Cloud (SFCC, formerly Demandware) realm: stock-outs on in-demand SKUs, stalled and failed orders, orders awaiting downstream sync, and integrations sitting on end-of-life API versions. It is not money you have lost; it is money at risk of slipping if the open issues are not worked. Think of it as the realm’s exposure gauge, a number that should sit near zero on a healthy estate and that climbs the moment something starts going wrong.

What it counts	The aggregated revenue exposure from currently-open risk signals across the realm. It rolls up the dollar (or display-currency) value attached to several sibling alert cards: in-demand SKUs that have gone out of stock, orders stuck in failed or stalled states, orders that have not synced downstream within the expected window, and revenue flowing through integrations on deprecated or soon-to-be-removed OCAPI / SCAPI versions.
Why it matters	It turns a scattered set of operational alerts into one number an owner or finance lead can watch. A merchant does not need to open six cards to know whether today is a quiet day or a fire; this card answers that in one glance, then the sibling cards tell you where the exposure is concentrated.
Reading the value	Zero (or close to it) is the target. Any non-zero value means at least one open issue carries revenue exposure. The figure is a live estimate, not a settled loss, working the underlying issues drives it back down. Read the trend, not just the level: a number creeping up over the day is an unfolding problem; a sudden jump is an incident.
What it is not	It is not realised loss, not refunds, and not a forecast. It is current exposure from open issues. When an issue is resolved (SKU restocked, order synced, integration upgraded) its contribution drops out of the total.
Composition	The total is the sum of contributions from its source signals. Because it spans inventory, orders, sync, and integration health, it can move for reasons that have nothing to do with each other. Always decompose it via the siblings before acting.
Currency	currency (display currency; on multi-currency realms the same mixed-currency caveat applies as for realm-wide revenue)
Unit	currency
Time window	RT (live exposure snapshot, recomputed on each refresh)
Alert trigger	>$0, any non-zero exposure raises the flag, because on a healthy realm this number should be zero
Sentiment key	scc_revenue_at_risk
Roles	owner, finance

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 retailer runs a single SFCC B2C realm with several DTC sites and a B2B portal. At 09:14 on 12 Jun 26 the card reads a non-zero exposure. Decomposing it across the source signals:

Risk source	Open issue	Illustrative exposure
Stock-out on in-demand SKUs	3 hero SKUs out of stock at the shared inventory list, high recent velocity	$48,000
Failed / stalled orders	22 orders in FAILED state from a payment gateway timeout window	$19,400
Orders awaiting downstream sync	64 orders confirmed in SFCC but not yet acknowledged by the OMS after 24h	$71,200
Integration on EOL API version	A LINK cartridge still calling a deprecated OCAPI version, carrying live checkout traffic	$0 today, flagged as forward risk
Revenue at Risk (live), this card		$138,600

Things to notice:

1. The headline is a roll-up, not a single cause. $138,600 looks alarming as one number, but it is three unrelated problems stacked together: a stock issue, a gateway issue, and a sync backlog. The card's job is to make you look; the siblings' job is to tell you where. Open [Orders Awaiting Downstream Sync (24h)](/nerve-centre/kpi-cards/salesforce-commerce-cloud/orders-awaiting-downstream-sync-24h) first here, it is the largest single contributor at$71,200.
2. The biggest exposure is recoverable, not lost. The $71,200 in unsynced orders is fully realisable revenue, the orders are confirmed and paid; they simply have not reached the OMS. The exposure exists because if the sync stays broken, fulfilment stalls and those orders can cancel or charge back. Fix the sync and the$71,200 drops straight out of this total.
3. The EOL integration contributes $0 today but is flagged. The deprecated OCAPI cartridge is still working, so it carries no current exposure, but it processes live checkout traffic and will break when the version is removed. Some configurations surface that forward risk here as a watch item rather than a dollar figure. Pair with Integrations on EOLd / EOL-Soon Versions.
4. The alert fired the instant the total left zero. Because the trigger is >$0, Vortex IQ flagged this the moment the first issue opened, not after it crossed a threshold. On a healthy realm this card sits at zero and stays quiet; the alert is essentially a “something needs working” signal for the whole estate.

Sibling cards merchants should reference together

Card	Why pair it with Revenue at Risk (live)
Orders Awaiting Downstream Sync (24h)	Often the largest single contributor. Confirmed, paid orders that have not reached the OMS are recoverable revenue at risk of stalling.
Failed Orders (24h)	Orders in FAILED state, usually a gateway or payment issue, feed directly into this total.
Stock-Out Burst	A sudden cluster of out-of-stocks on in-demand SKUs is one of the fastest ways this number climbs.
Order Processing Backlog	A growing backlog of unprocessed orders converts directly into exposure.
Integrations on EOLd / EOL-Soon Versions	Integrations on deprecated OCAPI / SCAPI versions carry forward risk to checkout and order flow.
OCAPI / SCAPI Failure Rate Spike or Version EOL Imminent	A failure-rate spike on the order APIs is a leading indicator that this number is about to rise.
Active Sites / Storefronts	A silent site drop is a top-tier risk event; read it alongside the exposure total.

Reconciling against Salesforce Commerce Cloud

Where to look in Business Manager:

There is no single Business Manager report that equals this card, because it is a Vortex IQ composite that stitches together signals SFCC exposes in different places. To verify each component:

• Stock-out exposure: Merchant Tools, Products and Catalogs, Inventory, check the relevant inventory list for the flagged SKUs and their allocation.
• Failed / stalled orders: Merchant Tools, Ordering, Orders, filter by status FAILED (and review confirmation_status) over the live window.
• Sync backlog: this is usually visible in your OMS or middleware rather than Business Manager directly; in SFCC, Merchant Tools, Ordering, Orders shows the confirmed orders, and the gap against OMS acknowledgement is the backlog.
• Integration / API version risk: Administration, Site Development, and the relevant OCAPI / SCAPI configuration; cross-check against Salesforce’s published version deprecation schedule.

Because the card is a live exposure estimate rather than a posted figure, treat Business Manager as the place to confirm each underlying issue, not to match the headline dollar amount exactly.

Why our number may legitimately differ from anything in Business Manager:

Reason	Direction of divergence
Composite by design. No single SFCC report sums inventory, order, sync, and integration risk together; this card does. There is nothing to match it against one-for-one.	Not comparable as a single figure
Live estimate, not posted. The figure is recomputed each refresh from currently-open issues; Business Manager reports settled order and inventory state.	Vortex IQ moves faster, by design
Recoverable vs realised. The total is exposure at risk, not loss. Most of it is recoverable revenue that never becomes a real loss once the issue is worked.	Vortex IQ higher than any realised-loss figure
Multi-currency rollup. On international realms the exposure can stitch together multiple currencies without FX, the same caveat as realm-wide revenue.	Material for international realms
Velocity assumptions. Stock-out exposure depends on recent SKU velocity; SFCC has no equivalent single “revenue at risk from this OOS” figure to compare to.	Estimate-dependent

Known limitations / merchant FAQs

Is this money I have already lost? No. It is revenue currently exposed by open issues, not realised loss. Most of it is recoverable: a confirmed order awaiting sync is still paid and still yours; restocking an out-of-stock SKU removes its contribution; upgrading an EOL integration removes that forward risk. The number is a call to action, not a tally of damage. When an issue is resolved its contribution drops out of the total.

Why does the alert fire at any non-zero value instead of a threshold? Because on a healthy realm this number should be zero. There are no open stock-outs on hero SKUs, no failed orders piling up, no sync backlog, and no integrations on dead API versions. A threshold would let small exposures accumulate silently. A >$0 trigger treats the card as a binary “something needs working” signal for the whole estate, then the siblings tell you what.

The number jumped suddenly. Where do I start? Decompose it. This card is a roll-up, so a jump is one (or more) of its sources moving. Open the siblings in this rough order of typical impact: Orders Awaiting Downstream Sync, Failed Orders, Order Processing Backlog, Stock-Out Burst, then the integration / API health cards. A sudden jump is usually an incident (a gateway timeout window, a sync outage); a slow climb is usually a backlog building.

Why is the time window “RT” and not a period? Exposure is a live state, not a flow over a window. There is no meaningful “30-day revenue at risk”, there is only how much is exposed right now. The card recomputes on each connector refresh, so a resolved issue stops counting almost immediately and a new one appears within a cycle.

Does it double-count if one order is both failed and unsynced? The composite is built to attribute each open issue to a single primary source so the headline does not double-count the same exposure. If you ever see the sum of the sibling figures exceed this card, that is the de-duplication at work, the card is the conservative single number; the siblings are the per-signal detail.

Why is the figure mixed-currency on our international realm? Same reason as realm-wide revenue: SFCC runs many sites in many currencies under one realm, and the live exposure can stitch them together without FX. For a clean single-currency read, decompose by site via the sibling cards or pin per-site panels. A base-currency rollup is on the connector roadmap.

Can I tune which signals feed this card? The composition is set by the connector’s risk model, but the alert threshold of each contributing signal (for example, what counts as an in-demand SKU for stock-out exposure, or how long an order can be unsynced before it counts) is configurable per profile in the Alert Rules tab. Tuning those changes what flows into this total.

It reads zero. Does that mean everything is perfect? It means none of the tracked risk signals are currently open: no exposed stock-outs, no failed or stalled orders, no sync backlog, no integrations on dead versions. That is the healthy state and the goal. It does not cover risks outside this card’s scope (for example, a marketing or pricing problem), so keep reading the rest of the Nerve Centre, but for operational exposure, zero is exactly what you want to see.

---

Tracked live in Vortex IQ Nerve Centre

Revenue at Risk (live) is one of hundreds of KPI pulses Vortex IQ tracks across Salesforce Commerce Cloud and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English.

Start for free or book a demo to see this metric running on your own data.