Commerce Architecture

Agentforce Commerce (formerly Commerce Cloud) is one of the most architecturally complex areas of the Salesforce ecosystem. 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 it entirely. The underlying technology stacks remain the same despite the 2025 rebrand.

Commerce Ecosystem Overview

Figure 1. B2C Commerce runs on the separate Demandware platform and requires explicit integration to reach CRM, while B2B Commerce shares native Salesforce objects. Order Management sits between both stacks and the ERP, handling post-purchase fulfillment for both channels.

B2C vs B2B vs B2B2C Comparison

This distinction drives almost every architecture decision. 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. 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
  ↓ overrides
Plugin Cartridges         ← LINK integrations (payment, tax, shipping)
  ↓ overrides
app_storefront_base       ← Salesforce-provided base functionality

CTA 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 simpler to integrate but designed for fundamentally different buying patterns.

Core Data Model

Figure 2. B2B Commerce uses standard Salesforce objects (Product2, Pricebook2, Order) throughout, enabling native data sharing with Sales Cloud and Service Cloud. The BuyerGroup and CommerceEntitlementPolicy chain controls which accounts see which products at which prices without custom code.

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

B2B Commerce uses standard Salesforce objects (Product2, Pricebook2, Order), so 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

Figure 3. The composable pattern decouples storefront presentation from the commerce engine, allowing web, mobile, kiosk, and voice channels to share one API layer. Third-party services for search, CMS, payment, and tax plug in independently, each replaceable without storefront rewrites.

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 gap catches many 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. Forcing 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 works fine

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 major 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

Figure 4. Buyer identity is the first fork: anonymous consumers route toward B2C Commerce while authenticated business accounts route toward B2B on the Salesforce platform. The dual-path outcome requires separate implementations sharing Order Management and Data Cloud as the integration layer.

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 Topics

• 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)