Salesforce B2B Commerce Architecture: The Hidden Complexity

The CloudCraze Legacy: Why B2B Commerce Feels Different

Salesforce B2B Commerce was not built by Salesforce. It was acquired in 2018 when Salesforce purchased CloudCraze, a managed package that had been running on the Salesforce platform since 2009. That acquisition history explains almost everything that confuses architects about B2B Commerce today.

CloudCraze was a sophisticated B2B commerce solution built entirely as a managed package using standard Salesforce objects, custom objects, Apex, and Visualforce. When Salesforce acquired it and rebranded it as B2B Commerce (now Salesforce B2B Commerce on Lightning), they inherited that architecture — including its opinionated data model, its own session management, its unique approach to pricing, and its distinct catalogue structure.

This is fundamentally different from, say, Service Cloud, which was designed as part of the core platform. B2B Commerce sits on top of Salesforce CRM but behaves like a separate product. It has its own store configuration, its own checkout process, its own guest user framework, and its own integration patterns. Architects who approach it expecting standard Salesforce patterns encounter friction quickly.

The good news is that the underlying Salesforce platform capabilities — Apex, SOQL, flows, integrations — all still apply. The complexity comes from understanding the B2B Commerce layer on top of those platform primitives and knowing which patterns to follow versus which to avoid.

The Core Data Model: Stores, Catalogues, and Products

B2B Commerce introduces several objects that don't exist in standard Salesforce CRM. Understanding their relationships is prerequisite to any architecture work.

WebStore: The top-level configuration object representing a storefront. Each store has its own catalogue, price book, checkout flow, and buyer access configuration. Most B2B implementations have one store, but multi-brand or multi-country deployments may have several — each with its own entitlement and pricing rules.

ProductCatalogue and ProductCategory: B2B Commerce manages its own product catalogue separate from the standard Salesforce Product2 object (though Product2 records are used as the product representation). The catalogue defines a hierarchy of categories that structures how products are browsed and searched. Category assignment controls navigation — products not assigned to a category are effectively invisible in the storefront.

Entitlement Policies and Buyer Groups: This is where most teams struggle. Entitlement policies define which products are visible to which buyers. Buyer Groups are collections of accounts that share the same entitlement policy and price book. An account must be assigned to a buyer group to access a store — without this, the buyer account exists in Salesforce CRM but cannot transact in Commerce.

CartItem and Order: The cart in B2B Commerce is a temporary order. When a buyer checks out, the cart is converted to a Salesforce Order. This means Order and OrderItem records are the commerce transaction record — and they carry all the constraints of standard Salesforce Orders (line item limits, order lifecycle, etc.).

// Example: Querying buyer group assignment for an account
SELECT Id, Name, BuyerGroupId, BuyerGroup.Name
FROM BuyerAccount
WHERE BuyerId = :accountId

// Example: Checking product entitlement
SELECT Id, Product.Name, CatalogueId
FROM ProductCatalogueProduct
WHERE CatalogueId IN (
  SELECT WebStoreCatalogueId
  FROM WebStoreCatalogue
  WHERE WebStoreId = :storeId
)

Pricing Architecture: The Four-Layer Model

B2B Commerce pricing is more complex than standard Salesforce CPQ pricing — and that complexity is often underestimated in project scoping. Pricing operates across four potential layers, each overriding the previous.

Layer 1 — List Price: The standard price from the Price Book Entry on the Product2 record. This is the baseline and applies to all buyers unless overridden at a lower layer.

Layer 2 — Price Book: Buyer groups are assigned a Price Book. If that Price Book has an entry for the product, it overrides the list price. This enables segment pricing — industrial buyers see $X, healthcare buyers see $Y for the same SKU.

Layer 3 — Volume Pricing (Price Adjustments): Quantity-based discounts defined as price adjustment tiers on a Price Book Entry. Buy 1-9 units at $100, 10-49 units at $90, 50+ units at $80. These are evaluated at cart time.

Layer 4 — Promotional Pricing: Coupons and promotions configured in the Commerce Promotions engine. These apply as adjustments to the resolved price from layers 1-3 and can be time-limited, segment-specific, or product-specific.

When architects scope B2B Commerce pricing requirements, they need to understand which of these layers are in play. The more complex the pricing model (contract pricing from ERP, account-specific negotiated rates, real-time availability-based pricing), the more customization is required and the more integration surface area is created.

Order Management System Integration

B2B Commerce generates Salesforce Orders, but Orders are typically not the end of the transaction. They need to flow to a fulfillment system — an ERP, a warehouse management system, or Salesforce's own Order Management product. This handoff is one of the most architecturally significant decisions in a B2B Commerce implementation.

Option 1 — Salesforce Order Management (OMS): Salesforce's own fulfillment product, designed to work natively with B2B Commerce. Orders flow from Commerce to OMS via standard platform events with no custom integration. OMS handles fulfillment orchestration, shipment tracking, and return management. This is the architecturally cleanest option but adds licensing cost and requires adopting OMS data models and flows.

Option 2 — ERP Integration via Middleware: Orders are published from Salesforce via Platform Events or outbound messages to an integration layer (MuleSoft, Boomi, custom) that transforms and routes to the ERP. The challenge here is order acknowledgment — the ERP must confirm order receipt and provide an order number, which needs to be written back to the Salesforce Order record. Design the acknowledgment loop carefully to avoid orphaned orders.

Option 3 — Real-time ERP Submission at Checkout: The checkout flow calls an ERP API synchronously to submit the order. Simpler from a data consistency standpoint but creates a hard dependency on ERP availability. If the ERP is down, checkout fails. This pattern is appropriate only when the ERP is highly available and the business requires synchronous order confirmation (e.g., printing a purchase order at checkout).

// Platform Event publish at Order activation for ERP integration
trigger OrderToERP on Order (after update) {
    List<Commerce_Order_Event__e> events = new List<Commerce_Order_Event__e>();
    for (Order o : Trigger.new) {
        Order old = Trigger.oldMap.get(o.Id);
        if (o.Status == 'Activated' && old.Status != 'Activated') {
            events.add(new Commerce_Order_Event__e(
                Order_Id__c = o.Id,
                Account_Id__c = o.AccountId,
                Total_Amount__c = o.TotalAmount,
                Event_Type__c = 'ORDER_SUBMITTED'
            ));
        }
    }
    if (!events.isEmpty()) {
        EventBus.publish(events);
    }
}

Performance Considerations for Large Catalogues

B2B Commerce performance degrades predictably as catalogue size grows. Architects need to understand the thresholds and the mitigation patterns before they become production incidents.

Product Search: B2B Commerce uses Salesforce's B2B Search index for product discovery. This index is separate from the main Salesforce search (Einstein Search) and requires explicit indexing of Product2 fields. The index rebuild time grows with catalogue size — for catalogues over 100K SKUs, indexing operations can take hours and may conflict with product data sync windows from PIM systems.

Category Tree Rendering: Category navigation is rendered from the category hierarchy configured in the catalogue. Deep category trees (5+ levels) with many sibling categories (50+) can cause slow storefront load times because category data is fetched on every page. Caching the category tree via a custom Apex class or using CDN-level caching for category data is a common optimization.

Cart Calculation: Each add-to-cart triggers a cart recalculation that evaluates entitlements, pricing tiers, and promotions for every item in the cart. For B2B buyers with large carts (100+ line items), this can result in 5-10 second recalculation times. Asynchronous cart calculation (available in recent releases) defers this to background processing and returns a "calculating" state to the buyer while the cart is refreshed.

B2B vs D2C: The Convergence Story

Salesforce operates two distinct Commerce products: B2B Commerce (the CloudCraze-derived solution) and B2C Commerce (formerly Demandware, acquired in 2016). These have historically been completely different architectures — B2B Commerce runs on the Salesforce platform as a managed package, while B2C Commerce is a separate SaaS application with its own runtime environment.

Salesforce's stated roadmap is convergence — a unified Commerce platform that serves both B2B and D2C (direct-to-consumer) scenarios. The LWR (Lightning Web Runtime) store template, introduced in recent releases, is the convergence vehicle. New B2B Commerce implementations should be built on LWR stores rather than the legacy Aura-based stores, as the legacy architecture is in maintenance mode.

The practical implication for architects today is: if your client needs both B2B and D2C commerce, evaluate whether the LWR store can handle both scenarios before recommending separate platform instances. The convergence is partial — the product catalogues, pricing engines, and order management remain separate — but the storefront layer and experience configuration are now shared.

Architecture Decision Points for B2B Commerce Projects

When leading a B2B Commerce architecture engagement, these are the decisions that shape everything downstream:

LWR vs Legacy Store: New implementations should always use LWR. Legacy Aura stores are in maintenance mode and will not receive new Commerce features. Any client on an older CloudCraze or legacy B2B Commerce instance should have a migration plan.

Headless vs Storefront Builder: B2B Commerce supports headless deployment — the storefront can be a separate React or Next.js application that calls Commerce APIs rather than using the built-in Salesforce storefront. Headless is appropriate for organisations with strong frontend development capabilities and complex UX requirements. The storefront builder is appropriate for standard B2B buying experiences where time-to-market and Salesforce-native management are priorities.

PIM Integration: Large B2B Commerce deployments invariably involve a Product Information Management system (Akeneo, Salsify, Stibo) as the source of truth for product data. The integration pattern (real-time sync via API, nightly batch, event-driven delta sync) determines how fresh product data is in the storefront and how complex the catalogue management process is. Design this integration early — it has significant impact on data volumes, indexing frequency, and operational overhead.

Guest Checkout: B2B Commerce supports guest browsing (unauthenticated) and guest checkout. The guest user model in Salesforce uses a single shared guest user profile, which has sharing and governor limit implications at scale. Many B2B implementations disable guest checkout entirely — B2B buyers are always authenticated — which simplifies the security model significantly.