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.
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.
What’s interesting:
- 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
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.
Cross-connector reconciliation (when the merchant has connected payment processors and analytics):
These connectors view the same orders through different lenses. They will not reconcile exactly, but the relationships are predictable.
Net of all processors: if you sum CyberSource + Adyen + PayPal + Worldpay + Apple Pay + manual + gift cards transaction counts, the total should sit close to this card minus
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.