Excludes failed/cancelled. Pairs with revenue to spot AOV-vs-volume issues.
At a glance
The count of distinct order rows on Salesforce Commerce Cloud (SFCC, formerly Demandware) for the period, summed across every site and locale in the realm. The denominator behind AOV and the volume side of every revenue conversation.
| What it counts | COUNT(DISTINCT order_no) across every order returned by SCAPI / OCAPI in the window. Each order increments by one regardless of basket size, currency, or status. |
| VAT / tax treatment | n/a, this is a count, not a value. |
| Shipping | n/a, count metric. |
| Discounts | n/a, count metric. |
| Refunds | NOT subtracted. A fully refunded order still counts as one. SFCC tracks refunds via separate Return / Credit objects; the original order row is unchanged. |
| Cancelled / voided orders | Included by default. SFCC keeps CANCELLED, FAILED, REPLACED, and REPLACEMENT order rows; the card sums all of them. Filter to confirmation_status = CONFIRMED for a “realised cash” view. |
| Currency | n/a for the count itself. The headline mixes orders from every site (USD DTC, GBP DTC, EUR, JPY, B2B). |
| Channels / sources | Multi-site by design. Every siteId in the realm contributes (DTC US, DTC UK, B2B portal, headless SCAPI sub-brand). Per-site filter is the right operational granularity on SFCC realms. |
| Replacement orders | SFCC’s replacement workflow creates a brand-new order with status REPLACEMENT and flips the original to REPLACED. By default both count, which double-counts the customer-facing event. To deduplicate, exclude status = REPLACED. |
| Time window | 30D vsP (default 30 days vs prior 30 days) |
| Alert trigger | drop >20% WoW, driven by sentiment_key: order_count_trend |
| Roles | owner, marketing, 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. Realm has four DTC sites (US, UK, DE, JP), one B2B portal, and one headless React storefront on SCAPI. The 30-day window covers 14 Mar 26 to 12 Apr 26.siteId | Site / locale | Orders | Notes |
|---|---|---|---|
RefArch-US | US DTC, en_US | 184,200 | Largest site by volume |
RefArch-UK | UK DTC, en_GB | 62,400 | |
RefArch-DE | Germany DTC, de_DE | 41,800 | |
RefArch-JP | Japan DTC, ja_JP | 28,600 | |
RefArch-B2B | B2B trade portal | 1,420 | 4% of orders, 22% of USD revenue |
Headless-Subbrand | Sub-brand on SCAPI | 12,800 | Same warehouse, separate siteId |
| Subtotal (CONFIRMED + COMPLETED) | 331,220 | Realised cash | |
CANCELLED (across realm) | 4,820 | Customer or fraud cancellations | |
FAILED (across realm) | 1,930 | Payment authorisation failures | |
REPLACEMENT (across realm) | 2,140 | New orders for returns / replacements | |
REPLACED (originals) | 2,140 | Pair of the replacement above | |
| Total Orders (this card, default) | 342,250 | All statuses summed |
- The default count is 342,250 but the realised-cash count is 331,220. The 11,030 gap (3.2%) is
CANCELLED+FAILED+REPLACED. Finance reads the realised-cash view; ops reads the default. The card defaults to “count everything” so the sum reconciles to SCAPI / OCAPI page counts, not the realised view. - Replacement double-counting is silently inflating by 2,140 orders. Every replacement workflow creates a new
REPLACEMENTrow and flips the original toREPLACED. Both count by default. Filterstatus != REPLACEDto deduplicate. This is per-merchant operational policy, not a bug. - B2B is 1,420 orders (0.4%) but 22% of USD revenue. The volume tile hides this entirely. Always pair Total Orders with Total Revenue, the same percentage move on the two cards means very different things.
- The 30-day prior window had 318,400 orders. Total Orders is up 7.5% vsP, well below the
drop >20% WoWalert threshold and trending healthy. The growth is concentrated on the US site (+9%) and the headless sub-brand (+24%); UK and DE are flat. Per-site panels surface this; the realm-wide headline does not.
Sibling cards merchants should reference together
| Card | Why pair it with Total Orders |
|---|---|
| Total Revenue | Total Revenue ÷ Total Orders = AOV. The same percentage move on the two cards means very different things; revenue up + orders flat is a basket-size shift, both up together is volume growth. |
| Average Order Value | The basket-size view. Lets you isolate volume-driven moves from value-driven moves. SFCC B2B AOV is typically 30-50× DTC AOV, so a small B2B count change moves AOV meaningfully. |
| Conversion Rate | The funnel view. Rising orders + flat sessions = conversion lift. Rising orders + rising sessions = traffic-led. |
| Refund Rate | This card is the gross order count. Refund Rate tells you how many of them came back via Returns / Credit Memos. |
| Orders by Status | The state-machine breakdown. Useful when the headline drops but you can’t see whether CANCELLED rose or COMPLETED fell. |
| New Customers | Same denominator. New-customer share of orders is a leading indicator on lifecycle health. |
adobe_commerce.order_count | Closest enterprise-tier peer for SFCC. Documentation cross-link only, not a reconciliation. |
shopify.order_count | Same metric on Shopify. Useful when an SFCC merchant is running a Shopify Plus pop-up alongside the SFCC realm. |
Reconciling against the vendor’s own dashboard
Where to look in Business Manager: SFCC’s admin tool is Business Manager at the per-realm URLhttps://<realm>.business.demandware.net. The closest like-for-like view is Merchant Tools, Site, Reports & Dashboards, Sales for any single site, or the cross-site Reports & Dashboards, Sales view if your role has multi-site read. Set the same date range, set the Status filter to “All” (the BM default is COMPLETED only), and read the Order Count column.
For multi-realm enterprise customers (production and staging realms), check you are comparing the same realm; sandbox order data should never appear in this card on a production-only Vortex IQ workspace.
Other Business Manager views that look like the same number but aren’t:
- Order Search: per-page count of matching orders, useful for spot-checks but not aggregated to a window.
- Reports & Dashboards, Returns: count of returns, not orders.
- Pricing & Promotion reports: counts of orders attributed to a specific promotion, narrower than this card.
| Reason | Direction | Why |
|---|---|---|
Order-status filter. BM Sales reports default to COMPLETED; Vortex IQ counts every status unless filtered. | Vortex IQ higher | Set BM filter to “All” and the gap closes to within timezone rounding. |
Site filter scope. BM defaults to the currently-selected site; Vortex IQ aggregates every siteId unless filtered. | Vortex IQ higher | Set BM to multi-site rollup or use Vortex IQ’s per-site filter. |
| Time-zone. BM uses the site’s configured time zone (US Eastern, GMT, JST, etc.); Vortex IQ runs on UTC by default. | Boundary days off | For a 30-day window the gap averages out; for “today” it can shift by a full day. |
| Order-export lag. SFCC’s data warehouse / Reports & Dashboards has a 5 to 30 minute lag from live SCAPI / OCAPI. | Vortex IQ slightly higher for the most recent hour | Self-resolves at next BM refresh. |
Replacement / Replaced pairs. BM may dedupe REPLACEMENT against the original REPLACED row; Vortex IQ counts both by default. | Vortex IQ higher when replacement-heavy | Filter status != REPLACED to match BM’s deduplicated view. |
B2B account-priced workflows. Some B2B sites use delayed confirmation (confirmation_status = NOT_CONFIRMED); BM may exclude these from the default Sales report. | Vortex IQ higher | Filter to confirmation_status = CONFIRMED to match. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
cybersource.cybersource_total_transactions | CyberSource ≤ SFCC Total Orders | CyberSource sees only orders paid via CyberSource. SFCC realms commonly run 3 to 5 PSPs (CyberSource + Adyen + PayPal + Worldpay + Apple Pay direct). Each one displaces CyberSource volume. |
stripe.stripe_total_charges | Stripe ≤ SFCC Total Orders | Stripe is rarely the dominant PSP on enterprise SFCC realms. Treat it as one of several. |
paypal.pp_total_transactions | PayPal ≤ SFCC Total Orders | PayPal-checkout orders only; subset by definition. |
google_analytics.ga_total_transactions | GA4 ≈ SFCC Total Orders × 0.75 to 0.90 | GA4 typically misses 10 to 25% of orders due to ad blockers, cookie rejection, and tag-fire failures. Larger gaps on JP / DE sites where consent rejection rates run higher. Treat SFCC as the source of truth for order count. |
CANCELLED / FAILED. A persistent gap > 2% means a payment processor is missing from your Vortex IQ workspace.
Known limitations / merchant FAQs
Why does my Total Orders count differ between Vortex IQ and Business Manager? The most common reason is the order-status filter. Business Manager’s default Sales view excludesFAILED and CANCELLED; Vortex IQ counts all order rows unless filtered. Set the BM filter to “All” and the numbers should converge to within timezone rounding. The second most common reason is site scope: BM is per-site by default; Vortex IQ aggregates every siteId in the realm.
Are B2B portal orders counted the same as DTC orders?
Yes, every confirmed SFCC order increments this card by one regardless of channel. On enterprise realms with active B2B portals, this is rarely what you want operationally because B2B AOV is 30 to 50 times DTC AOV; one B2B order has the same weight here as one DTC order. Pair with Total Revenue and basket-size aware views, and use the per-site filter to read DTC and B2B independently.
My replacement-order workflow inflates the count. Why?
SFCC’s REPLACEMENT status is a brand-new order created when an existing order is reissued (typically to fulfil a return or to fix an item-level error). The original keeps REPLACED status. By default the card counts both, which double-counts the customer-facing event. To correct: filter out REPLACED so only the live order remains. This is a per-merchant operational choice; the card defaults to “count everything” so finance reconciles cleanly.
Why does the card flatten across all my sites? I want a per-site read.
Per-site reads are the right granularity for operational reviews on SFCC realms. Pin a per-site panel using the filter in the Nerve Centre. The realm-wide total is mostly useful as a navigation anchor and for trend-shape comparisons across sites.
How is this different from “checkout count” or “session count”?
This card counts confirmed orders only (rows in the Order index). A “checkout” can fail or abandon at the payment step, so checkout count is always higher than order count. Session count is higher again (every visitor session that loaded a cart). Use Conversion Rate for sessions-to-orders, and BM Reports & Dashboards for the upper-funnel checkout-attempt count.
Do guest orders count separately from registered-customer orders?
Yes, they all count once in Total Orders. SFCC distinguishes via the customer.customer_no and customer.customer_id fields; guests are typically customer_no = null. To split them, use a per-card filter on customer_id IS NOT NULL for registered, and the inverse for guests. Guest-share trends are a useful health signal on DTC sites (rising guest-share = fewer returning customers = retention concern).
During peak (BFCM, end of season), the count looks unrealistically high one hour and lower the next. Why?
SFCC’s order-confirmation pipeline is asynchronous: orders move from CREATED to OPEN to COMPLETED over seconds to minutes, and confirmation_status flips when payment is captured. During BFCM peaks the CREATED-to-OPEN lag stretches. The card reads order rows as soon as they exist; for “realised cash” orders, filter confirmation_status = CONFIRMED. The aggregate-only number stabilises within 1 hour after peak load eases.