Commerce Architecture
Commerce Cloud is one of the most architecturally complex areas of the Salesforce ecosystem because it spans two fundamentally different technology stacks. A CTA must understand where each commerce product lives, how they integrate with core CRM, and when to recommend each approach — or when to avoid Commerce Cloud entirely.
Commerce Ecosystem Overview
graph TB
subgraph "Salesforce Commerce Ecosystem"
direction TB
subgraph B2C["B2C Commerce (Demandware)"]
B2C_SFRA[SFRA Storefront]
B2C_PWA[Composable Storefront / PWA Kit]
B2C_API[SCAPI + OCAPI]
B2C_BM[Business Manager]
B2C_MRT[Managed Runtime]
end
subgraph B2B["B2B / D2C Commerce (Core Platform)"]
B2B_LWR[LWR Storefront]
B2B_EB[Experience Builder]
B2B_APEX[Apex Extensions]
B2B_API2[Connect API]
B2B_DATA[Product2 / WebStore Objects]
end
subgraph SOM["Salesforce Order Management"]
SOM_OL[Order Lifecycle]
SOM_FF[Fulfillment Flows]
SOM_PAY[Payment Gateway]
end
subgraph CRM["Core CRM"]
SC[Service Cloud]
SALESC[Sales Cloud]
MC[Marketing Cloud]
DC[Data Cloud]
end
end
B2C_SFRA --> B2C_API
B2C_PWA --> B2C_API
B2C_API --> SOM
B2B_LWR --> B2B_API2
B2B_API2 --> SOM
SOM --> CRM
B2B_DATA --> SALESC
DC --> B2C
DC --> B2B
MC --> B2C
MC --> B2B
ERP[ERP System] --> SOM
PIM[PIM / MDM] --> B2C_BM
PIM --> B2B_DATA
style B2C fill:#1a365d,stroke:#2a4a7f,color:#fff
style B2B fill:#2d6a4f,stroke:#1b4332,color:#fff
style SOM fill:#7b2d8b,stroke:#5a1d6b,color:#fff
style CRM fill:#c2410c,stroke:#9a3412,color:#fff
B2C vs B2B vs B2B2C Comparison
This is the single most important distinction. B2C Commerce and B2B Commerce are built on entirely different technology stacks.
| Dimension | B2C Commerce | B2B Commerce | B2B2C / D2C Commerce |
|---|---|---|---|
| Origin | Demandware acquisition (2016) | Built natively on Salesforce platform | Extension of B2B Commerce |
| Platform | Separate multi-tenant cloud | Core Salesforce Platform | Core Salesforce Platform |
| Tech stack | JavaScript, Node.js, ISML | Apex, LWC, LWR | Apex, LWC, LWR |
| Storefront | SFRA or Composable (PWA Kit) | Experience Builder + LWR | Experience Builder + LWR |
| Data model | Proprietary (products, catalogs, slots) | Standard objects (Product2, WebStore, BuyerGroup) | Shared B2B data model |
| Hosting | Salesforce-managed CDN + instances | Salesforce core platform (multi-tenant) | Salesforce core platform |
| Admin tool | Business Manager | Salesforce Setup + Commerce app | Salesforce Setup + Commerce app |
| APIs | SCAPI (Shopper) + OCAPI (Data/Shop) | Connect API, REST API | Connect API, REST API |
| Order volume | High volume, small carts (< 10 items) | Low volume, large carts (100+ items) | Varies by use case |
| Pricing | Price books, promotions, coupons | Negotiated, tiered, contract-based + entitlements | Consumer or contract-based |
| Customization | Cartridge architecture (overlay model) | Standard Apex/LWC extensibility | Standard Apex/LWC extensibility |
| CRM integration | Requires explicit integration (B2C CRM Sync) | Native — shares Account, Contact, Order objects | Native — shares core CRM objects |
| Typical buyer | Anonymous consumers | Authenticated business accounts | Both consumer and business |
Critical CTA Distinction
B2C Commerce is NOT built on the Salesforce Platform. It is a completely separate technology stack acquired from Demandware. This means it has its own data model, its own admin console (Business Manager), its own deployment pipeline, and requires explicit integration with core Salesforce CRM. Many candidates wrongly assume it runs on the same platform as Sales/Service Cloud.
B2C Commerce Architecture
Instance Architecture
B2C Commerce uses a dedicated instance model, not the standard Salesforce multi-tenant architecture:
| Instance Group | Instances | Purpose |
|---|---|---|
| Primary (PIG) | Development, Staging, Production | Core development, testing, and live operations |
| Secondary (SIG) | 3-47 Sandboxes | Parallel development, partner work, experimentation |
Storefront Architecture Options
| Approach | Technology | Use When |
|---|---|---|
| SFRA | Server-side JS, ISML templates, MVC pattern | Existing B2C implementations, teams with SFCC expertise |
| Composable Storefront (PWA Kit) | React, Node.js, Managed Runtime | New builds, performance-critical, headless architecture |
| Hybrid (Phased Headless) | SFRA backend + PWA frontend overlay | Incremental migration from SFRA to headless |
SFRA Cartridge Architecture
SFRA uses a layered cartridge stack where higher cartridges override lower ones:
Custom Cartridge ← Client-specific customizations ↓ overridesPlugin Cartridges ← LINK integrations (payment, tax, shipping) ↓ overridesapp_storefront_base ← Salesforce-provided base functionalityCTA Exam Relevance
In a CTA scenario involving B2C Commerce, focus on integration architecture rather than storefront implementation details. The review board cares about how commerce data flows to CRM, Order Management, and Marketing — not about ISML template syntax.
B2B Commerce Architecture
B2B Commerce runs natively on the Salesforce Platform, making it architecturally simpler to integrate but designed for fundamentally different buying patterns.
Core Data Model
erDiagram
WebStore ||--o{ WebStoreCatalog : contains
WebStoreCatalog ||--|| ProductCatalog : references
ProductCatalog ||--o{ ProductCategory : organizes
ProductCategory ||--o{ Product2 : contains
Product2 ||--o{ PricebookEntry : "priced in"
Pricebook2 ||--o{ PricebookEntry : contains
WebStore ||--o{ WebStoreBuyerGroup : "accessible by"
WebStoreBuyerGroup ||--|| BuyerGroup : references
BuyerGroup ||--o{ BuyerGroupMember : contains
BuyerGroupMember ||--|| Account : "linked to"
BuyerGroup ||--o{ CommerceEntitlementPolicy : "governed by"
CommerceEntitlementPolicy ||--o{ CommerceEntitlementProduct : "grants access to"
CommerceEntitlementProduct ||--|| Product2 : "entitles"
WebStore ||--o{ WebCart : "shopping in"
WebCart ||--o{ CartItem : contains
CartItem ||--|| Product2 : references
WebCart ||--|| Order : "converts to"
Order ||--o{ OrderItem : contains
Key B2B Commerce Objects
| Object | Purpose | CTA Relevance |
|---|---|---|
| WebStore | Hub object — represents the storefront site | One per storefront; all commerce data hangs off this |
| Product2 | Standard product object shared with Sales Cloud | Unifies product data across commerce and CRM |
| BuyerGroup | Groups of buyer accounts with shared pricing/entitlements | Controls who sees what products at what prices |
| CommerceEntitlementPolicy | Controls product visibility per buyer group | Critical for B2B scenarios with restricted catalogs |
| WebCart / CartItem | Shopping cart objects | Maps to Order/OrderItem on checkout |
| Pricebook2 / PricebookEntry | Standard Salesforce price book model | Supports tiered, negotiated, and contract pricing |
Shared Data Model Advantage
Because B2B Commerce uses standard Salesforce objects (Product2, Pricebook2, Order), it natively shares data with Sales Cloud and Service Cloud. No integration layer needed for CRM visibility — a major architectural advantage over B2C Commerce.
Headless and Composable Commerce
Headless commerce decouples the storefront presentation layer from the backend commerce engine, enabling greater flexibility and omnichannel delivery.
Composable Architecture
graph LR
subgraph Frontend["Frontend Layer"]
PWA[PWA Kit / React]
MOBILE[Mobile App]
KIOSK[In-Store Kiosk]
VOICE[Voice Assistant]
end
subgraph API["API Layer"]
SCAPI[Commerce API - SCAPI]
SLAS[Shopper Login & API Access Service]
end
subgraph Backend["Commerce Backend"]
CAT[Catalog & Products]
PRICE[Pricing & Promotions]
INV[Inventory]
CART[Cart & Checkout]
SEARCH[Product Search]
end
subgraph ThirdParty["Composable Services"]
CMS[Headless CMS]
SRCH[Search Provider]
PAY[Payment Provider]
TAX[Tax Engine]
end
PWA --> SCAPI
MOBILE --> SCAPI
KIOSK --> SCAPI
VOICE --> SCAPI
SCAPI --> SLAS
SCAPI --> Backend
PWA --> CMS
PWA --> SRCH
SCAPI --> PAY
SCAPI --> TAX
style Frontend fill:#1a365d,stroke:#2a4a7f,color:#fff
style API fill:#7b2d8b,stroke:#5a1d6b,color:#fff
style Backend fill:#2d6a4f,stroke:#1b4332,color:#fff
style ThirdParty fill:#c2410c,stroke:#9a3412,color:#fff
When to Go Headless
| Go Headless When | Stay Coupled When |
|---|---|
| Omnichannel delivery (web, mobile, kiosk, IoT) | Single web storefront only |
| Performance is critical (sub-second page loads) | Small catalog, simple experience |
| Custom UX beyond template capabilities | Team lacks React/frontend expertise |
| Multiple brands sharing one commerce backend | Tight timeline, need quick launch |
| Content-rich experiences requiring CMS flexibility | Budget constraints on frontend development |
| Progressive migration from legacy storefront | Business users need full self-service control |
Headless Complexity
Headless commerce adds significant architectural complexity. You must manage a separate frontend deployment pipeline (Managed Runtime), API authentication (SLAS), CDN caching strategy, and SEO considerations (server-side rendering). Only recommend headless when the business requirements genuinely demand it.
Salesforce Order Management (SOM)
SOM is a separately licensed product that provides post-purchase order lifecycle management. It sits between Commerce and fulfillment systems.
SOM Architecture
| Component | Function |
|---|---|
| Order Lifecycle | Status tracking from placement through fulfillment to completion |
| Fulfillment Orders | Splitting orders across locations, warehouses, drop-ship partners |
| Flow-Based Orchestration | Fulfillment logic built with Flow Builder — declarative routing |
| Payment Integration | Capture, refund, and partial payment processing via gateway adapters |
| Return Management | RMA creation, return processing, exchange handling |
| Inventory Availability | Real-time inventory checks across locations (requires integration) |
SOM Integration Points
| Integration | Direction | Pattern |
|---|---|---|
| B2C Commerce to SOM | Commerce —> SOM | Order placement via API; async event-driven |
| B2B Commerce to SOM | Commerce —> SOM | Native platform — Order object shared |
| SOM to ERP | SOM —> ERP | Fulfillment events pushed to ERP for warehouse/logistics |
| SOM to Service Cloud | Bidirectional | Agents view order status, initiate returns, modify orders |
| SOM to Marketing Cloud | SOM —> MC | Transactional emails (shipping confirmation, delivery updates) |
Commerce Integration Patterns
Integration with Core CRM
| Cloud | B2C Commerce Integration | B2B Commerce Integration |
|---|---|---|
| Sales Cloud | B2C CRM Sync connector maps customers to Contacts/Person Accounts | Native — shares Account, Contact, Opportunity objects |
| Service Cloud | Order data synced via middleware or Connect APIs | Native — agents see orders, carts, entitlements directly |
| Marketing Cloud | Marketing Cloud Connector for journey triggers, behavioral data | Data Cloud + Marketing Cloud engagement |
| Data Cloud | Commerce data ingestion for unified customer profiles | Native data flow into Data Cloud |
| Experience Cloud | N/A (separate storefront) | B2B storefront IS an Experience Cloud site |
B2C CRM Sync Limitations
B2C CRM Sync (formerly Commerce Cloud Connector) is not real-time. It syncs customer profiles and order history on a schedule. For real-time order status in Service Cloud, you need middleware or custom API integration. This is a common gap that catches architects off guard.
ERP Integration Architecture
Commerce-to-ERP integration is almost always required. Common patterns:
| Data Flow | Direction | Frequency | Pattern |
|---|---|---|---|
| Product master data | ERP —> Commerce | Batch / near-real-time | PIM feed or middleware sync |
| Pricing and contracts | ERP —> Commerce | Batch | Price book sync via integration |
| Inventory availability | ERP —> Commerce | Near-real-time | API call or cache-based availability |
| Order placement | Commerce —> ERP | Real-time / near-real-time | Event-driven via middleware |
| Order status / fulfillment | ERP —> Commerce | Near-real-time | Webhook or polling pattern |
| Customer/account data | Bidirectional | Near-real-time | Master data sync via middleware |
CTA Scenario Use Cases
Scenario 1: Global Retailer with D2C and Wholesale Channels
Situation: A global fashion brand sells direct-to-consumer via web and mobile, and also supplies wholesale buyers (department stores, boutiques). They have 50K SKUs, seasonal catalogs, and operate in 12 countries with multi-currency pricing.
Architecture decision:
- B2C Commerce (Composable Storefront) for D2C channel — high-volume consumer traffic, performance-critical, needs localization per market, headless for mobile app reuse
- B2B Commerce for wholesale portal — authenticated buyers, negotiated pricing, bulk ordering, reorder from previous orders
- Salesforce Order Management for unified post-purchase lifecycle across both channels
- Data Cloud as the unified customer profile layer connecting commerce behavior with CRM data
- Middleware (MuleSoft) for ERP integration — inventory sync, order fulfillment, financial reconciliation
Why not a single platform? The buying patterns are fundamentally different. Consumer shoppers browse and buy small quantities at listed prices. Wholesale buyers log in, see contracted prices, order hundreds of units, and need approval workflows. Trying to force both onto one commerce platform creates compromises in both experiences.
Scenario 2: Manufacturing Company Launching Self-Service Parts Portal
Situation: A heavy equipment manufacturer wants to enable customers and dealers to order replacement parts online. Currently all orders go through a call center. They have 200K part SKUs with complex compatibility rules (part X fits machine models A, B, C but not D).
Architecture decision:
- B2B Commerce on LWR — runs natively on Salesforce Platform, integrates with existing Service Cloud and Field Service implementations
- Custom LWC compatibility checker embedded in the storefront — queries a custom object mapping parts to machine models
- Entitlement policies to control which dealers see which products and pricing tiers
- Service Cloud integration for warranty validation before part orders
- No SOM needed — order volume is low enough that standard Order processing with Flow-based fulfillment logic suffices
Why B2B Commerce over B2C? The buyers are authenticated business accounts, pricing is contract-based, and the tight integration with existing Service Cloud and Field Service is a massive advantage of staying on-platform.
Scenario 3: CPG Brand Launching Direct-to-Consumer for the First Time
Situation: A consumer packaged goods company traditionally sells through distributors. They want to launch a D2C website to build direct customer relationships, capture first-party data, and test new products before wholesale distribution.
Architecture decision:
- B2C Commerce with SFRA for speed to market — SFRA provides a production-ready storefront template that can launch in 8-12 weeks
- Marketing Cloud for abandoned cart recovery, post-purchase nurture, and loyalty program communications
- Data Cloud to build unified profiles combining commerce purchase data with marketing engagement data
- Start without SOM — use basic OMS capabilities in B2C Commerce for initial launch; migrate to SOM when order complexity warrants it
- Plan for headless migration — start with SFRA to launch fast, then migrate to Composable Storefront once the team builds React expertise
Why not B2B Commerce D2C template? The CPG brand needs consumer-grade shopping experiences (visual merchandising, promotions, flash sales, SEO optimization) that B2C Commerce handles better. D2C templates on the Salesforce Platform work well for simpler catalogs but lack the merchandising depth needed for consumer brands.
Decision Guide: Choosing a Commerce Platform
flowchart TD
START([Commerce<br/>Requirement]) --> Q1{Who is<br/>the buyer?}
Q1 -->|Anonymous consumers| Q2{Need rich<br/>merchandising?}
Q1 -->|Authenticated businesses| Q5{Already on<br/>Salesforce Platform?}
Q1 -->|Both| Q8[Dual Platform Strategy]
Q2 -->|Yes| Q3{High traffic<br/>> 1M sessions/mo?}
Q3 -->|Yes| R1[B2C Commerce<br/>Composable Storefront]
Q3 -->|No| Q4{Team has<br/>React expertise?}
Q4 -->|Yes| R1
Q4 -->|No| R2[B2C Commerce<br/>SFRA]
Q2 -->|No - simple catalog| R3[D2C Commerce<br/>on Platform]
Q5 -->|Yes| Q6{Complex pricing<br/>and entitlements?}
Q5 -->|No| Q7{Budget for separate<br/>platform?}
Q6 -->|Yes| R4[B2B Commerce<br/>on LWR]
Q6 -->|No| R3
Q7 -->|Yes| R4
Q7 -->|No| R5[Evaluate AppExchange<br/>or Custom Build]
Q8 --> R6[B2C Commerce + B2B Commerce<br/>with shared SOM + Data Cloud]
style R1 fill:#1a365d,stroke:#2a4a7f,color:#fff
style R2 fill:#1a365d,stroke:#2a4a7f,color:#fff
style R3 fill:#2d6a4f,stroke:#1b4332,color:#fff
style R4 fill:#2d6a4f,stroke:#1b4332,color:#fff
style R5 fill:#f4a261,stroke:#d4823e,color:#000
style R6 fill:#7b2d8b,stroke:#5a1d6b,color:#fff
Common Gotchas
Licensing Complexity
Commerce Cloud licensing is separate from core Salesforce licensing. B2C Commerce is licensed by Gross Merchandise Value (GMV) — a percentage of revenue processed through the platform. B2B Commerce is licensed per org. SOM is separately licensed. Always factor licensing costs into TCO analysis.
B2C Commerce Data Isolation
B2C Commerce customer data (shopper profiles, order history, browsing behavior) lives in the B2C Commerce instance, NOT in Salesforce CRM. You must explicitly integrate this data into Sales/Service Cloud. Without integration, service agents cannot see a customer’s online order history.
No Single Commerce Platform Covers Everything
Salesforce does not have a single unified commerce product. B2C and B2B are fundamentally different platforms. Do not promise a client “one Salesforce Commerce solution” for both consumer and business buyers — this requires two implementations with a shared integration layer.
Einstein Commerce Recommendations Require Data Volume
Einstein Product Recommendations in B2C Commerce benefits from historical transaction data. Two years of data is ideal per official docs, but recommendations begin working soon after launch. No hard minimum transaction threshold is documented. Plan for a phased rollout and expect recommendation quality to improve as data accumulates.
Related Content
- Build vs Buy — Framework for evaluating Commerce Cloud vs custom e-commerce solutions
- Decision Guides — Additional solution architecture decision flowcharts
- Integration — Integration patterns applicable to commerce-to-CRM data flows
- Data Modeling — Commerce data model considerations within broader org design
- Clouds, Products & Licensing — Commerce Cloud licensing details
Sources
- Salesforce B2C Commerce Architecture (Salesforce Developers)
- SFRA Overview (Salesforce Developers)
- B2B Commerce Developer Guide (Salesforce Developers)
- B2B Commerce Data Model (Salesforce Developers)
- PWA Kit Overview (Salesforce Developers)
- Architecture of B2C Commerce (Trailhead)
- B2B Commerce Data Model (Trailhead)
- B2B2C Commerce Data Model (Trailhead)
- B2C Commerce vs B2B Commerce Differences (Salesforce Ben)
- B2C Commerce Architecture Explained (Salesforce Ben)
- Salesforce Order Management (Salesforce Help)
- Integration Architecture for B2B Stores (Salesforce Developers)