Commerce Cloud B2B and B2C: Architecture Decisions for Hybrid Commerce

Salesforce Commerce Cloud offers separate storefronts for B2C (SFCC/Storefront Reference Architecture) and B2B (B2B Commerce, now also available as Lightning-based B2B). Increasingly, clients want hybrid architectures - B2C-style UX for business buyers, B2B pricing and account management, single backend. Here’s what those architectures actually look like and the decisions that matter.

B2C vs B2B: The Core Differences

Before designing anything, be clear on what’s actually different:

The mistake I see most often: treating B2B commerce as “B2C with a price list change.” The checkout flow, account model, and post-order service flows are fundamentally different.

B2B Account Hierarchy

The B2B data model in Salesforce is built around the Account hierarchy. Get this wrong and nothing else works:

Corporate Account (parent)
    ├── Division A (child account)
    │     ├── Buyer Contact (role: Buyer)
    │     ├── Buyer Contact (role: Approver)
    │     └── AccountGroup → Pricebook → Contract Pricing
    └── Division B (child account)
          └── Buyer Contact (role: Buyer)

Key decisions: Where does the pricebook live? - at the corporate level (all divisions see the same prices), at the division level (each division has a negotiated price), or at the account group level (segments of accounts share a price tier). Mixing these creates a maintenance nightmare. Pick one.

Who can approve orders? - define the approval hierarchy as Salesforce roles or custom fields on the Contact. Implement approval via a Flow that routes to the designated approver based on order value thresholds.

How do new buyer contacts get provisioned? - self-registration via Experience Cloud with manager approval, or admin-provisioned by the account rep? Self-registration is scalable but requires a validation step (prevents competitors from registering on your B2B site).

Pricing Architecture

B2B pricing is the most complex part of any Commerce Cloud implementation. The layers:

Standard pricebook - list price, visible to all. Contract pricebook - account or account-group-specific negotiated price. Overrides standard. Volume tiers - price per unit decreases as quantity increases. Model with PricebookEntry + custom tier table or use B2B Commerce’s native tiered pricing object. Promotional pricing - time-limited discount on top of contract price. Decide upfront whether promotions apply before or after contract pricing.

Final price = min(contract price, promotional price) × (1 - volume discount %)

Implement price calculation in Apex and expose it via a single service class used by both the storefront and any API. Never replicate pricing logic in multiple places.

Checkout Flow Design

B2B checkout has more states than B2C:

Cart → Validate addresses → Apply account pricing
     → Check credit limit → Request PO number
     → Approval workflow (if order > threshold)
     → Place order → Fulfilment

The approval workflow is the piece most implementations underspecify. You need:

• Threshold configuration per account (£5,000 for one client, £50,000 for another)
• Approver routing - escalation path if the primary approver doesn’t respond within N hours
• Partial approval - can an approver approve some line items and reject others?
• Approver mobile UX - approvers often need to act from mobile. Make the approval page first-class mobile.

Implement in Flow with a Queueable for async notification to approvers. Don’t implement in Apex triggers - you’ll be maintaining that code forever.

Shared Infrastructure for Hybrid B2B/B2C

When a client runs both B2B and B2C, the question is how much to share. My default position:

Share: product catalogue, inventory data, order management (OMS), payment gateway integration, customer data platform (Data Cloud unified profiles)

Separate: storefront UI (B2C has discovery/browse UX; B2B has quick-order/reorder UX), authentication (B2C: consumer identity; B2B: corporate SSO), pricing engine (fundamentally different logic)

The unified product catalogue is the most valuable shared component. Maintain one product taxonomy, one set of product attributes, one content model. Surface different views to each channel via metadata or segmentation, but maintain a single source of truth.

Experience Cloud as B2B Portal

Salesforce B2B Commerce integrates with Experience Cloud for the buyer portal. Key configuration decisions:

Authentication - B2B buyers should authenticate via SSO from their corporate IdP if possible. Reduces password management for the buyer and gives the corporate IT team visibility into who is accessing your portal.

Self-service order history - expose OrderSummary and FulfillmentOrder data to authenticated buyers without custom development. Use the standard Order Management FlexCards or build custom LWC components.

Punchout catalogue (cXML/OCI) - if your B2B buyers use procurement platforms (SAP Ariba, Coupa, Oracle), they need punchout integration. Implement early - it’s more complex than most teams expect and procurement platform testing is slow.

Order Management Integration

B2B order volumes per order are higher; order frequency may be lower. This changes the OMS design:

• Minimum order quantities - enforce in the cart, not at OMS routing time
• Backorder handling - B2B buyers often accept backorders. Build an explicit backorder confirmation step with an estimated ship date
• Split billing - a single order might be billed to multiple cost centres. Model with multiple OrderPaymentSummary records or a custom billing reference object
• EDI integration - large B2B accounts may send orders via EDI rather than the web portal. Design OMS to accept orders from multiple ingestion channels with the same fulfilment flow

Reporting for Hybrid Commerce

B2C metrics: conversion rate, average order value, cart abandonment, customer acquisition cost. B2B metrics: account revenue, contract utilisation (% of contract minimum hit), account penetration (products purchased vs catalogue breadth), order frequency.

Build separate dashboards. The B2C metrics are meaningless for evaluating B2B account health, and vice versa. Use Data Cloud to unify the underlying data while keeping reporting views distinct.