SfSkills Domains Docs GitHub

Home / architect / b2b-vs-b2c-architecture

b2b-vs-b2c-architecture

Use this skill when designing or evaluating the architecture of a Salesforce Commerce implementation that involves choosing between B2B Commerce (on Core, Lightning platform) and B2C Commerce (Salesforce Commerce Cloud / SFCC).

Open the skill folder on GitHub

B2B vs B2C Commerce Architecture

This skill activates when an architect or senior practitioner must evaluate the structural, data model, extensibility, and integration differences between Salesforce B2B Commerce (running on the Core Salesforce platform) and Salesforce B2C Commerce (Salesforce Commerce Cloud, SFCC), to make or validate a platform architecture decision. It does not cover implementation mechanics — those belong to the admin-domain skills for each platform.

Before Starting

Gather this context before working in this domain:

Core Concepts

1. Infrastructure Layer: Shared Core vs. Separate Hosted Platform

B2B Commerce on Core is a native Lightning platform application. It runs inside the same Salesforce org that houses CRM data (Accounts, Contacts, Opportunities, Orders). Storefront rendering uses the Lightning Web Runtime (LWR) and Experience Cloud. Customization uses Apex, LWC, and Flow. All commerce objects (WebStore, BuyerGroup, CommerceEntitlementPolicy, OrderSummary) are standard Salesforce objects in the same org database. Governance is through standard Salesforce governor limits: SOQL query limits, DML limits, CPU time limits per transaction.

Salesforce B2C Commerce (SFCC) is a separate, hosted platform with dedicated infrastructure. It has its own server environments (Primary Instance Group, sandbox instances), its own database, its own admin UI (Business Manager), and its own deployment model (cartridge uploads, code version activations). There is no Salesforce org, no SOQL, no Apex, no Flow. Customization uses SFRA (Storefront Reference Architecture) — a Node.js-based cartridge system — and the Business Manager extension framework. SFCC exposes data through its own Open Commerce API (OCAPI) and SCAPI (Shopper Commerce API), which are HTTP REST APIs with no relationship to Salesforce REST/SOAP APIs.

Architectural implication: CRM integration with SFCC is always an external integration (via connected app, OMS connector, or custom middleware). CRM integration with B2B Commerce on Core is zero-latency because both systems share the same org — there is no integration layer between the commerce objects and the CRM objects.

2. Data Model: CRM-Native Objects vs. SFCC-Proprietary Data Store

B2B Commerce on Core data model (key objects):

Because these objects live in the Salesforce org, they are queryable via SOQL, accessible in Flow, triggerable with Apex, reportable in CRM Analytics, and available to any integration connected to the org.

SFCC data model:

Architectural implication: Any scenario that requires real-time access to CRM data (account-based pricing, rep-assisted selling, quote-to-order) requires a custom integration layer in SFCC. In B2B Commerce on Core, this data is available natively.

3. Extensibility Model: Flow/Apex/LWC vs. SFRA Cartridges and Commerce Extensions

B2B Commerce on Core — extensibility paths:

PathRole
Checkout FlowThe entire checkout process is a Salesforce Flow (CheckoutFlow type). Each step (address, delivery, payment) is a flow element that can be overridden with custom screen components. No code required for standard paths.
Commerce Extensions (Winter '24+)Custom Apex classes registered as commerce service implementations for pricing, inventory, shipping, and tax. They run synchronously within the checkout flow and replace the default platform behavior. Applies to B2B Commerce and D2C Commerce on Core only.
LWCAll storefront UI components are LWC components, reusable from the org's component library.
ApexAll business logic, trigger handlers, and service implementations are Apex, subject to governor limits.

SFCC — extensibility paths:

PathRole
SFRA cartridgesThe primary customization unit. A cartridge is a Node.js module that extends or overrides storefront behavior. Cartridges are layered in a path (cartridgePathOverride); the first matching controller or template wins. Custom cartridges override SFRA base cartridge behavior without modifying the base.
Business Manager extensionsCustom UI modules for back-office admin workflows.
Pipelines (legacy) / Controllers (current)Server-side rendering controllers that handle HTTP requests, call service layers, and render ISML templates.
HooksDeclarative extension points within SFCC's system that allow code injection at defined pipeline steps (e.g., app.payment.handle, app.order.calculate).
SCAPI / OCAPIREST APIs that allow external systems (headless front ends, mobile apps) to interact with SFCC as a commerce engine without the SFRA rendering layer.

Architectural implication: B2B Commerce customization requires Salesforce platform skills (Apex, Flow, LWC). SFCC customization requires Node.js, SFRA cartridge architecture, and Business Manager knowledge. These are separate skill sets; team capability is a first-class architectural constraint.

4. Integration Surface and API Architecture

B2B Commerce on Core:

SFCC:

Common Patterns

Pattern 1: B2B Commerce on Core for Quote-to-Order with CRM Integration

When to use: The buyer is a known business account with negotiated pricing. The sales team uses Salesforce CRM (Accounts, Opportunities, Quotes) and needs the commerce store to be an extension of the sales process — not a separate system. Order data must flow into Salesforce Order Management. Real-time account entitlement checking is required.

How it works:

  1. B2B Commerce WebStore is provisioned inside the existing Salesforce org.
  2. BuyerGroup and CommerceEntitlementPolicy records mirror the Account tier structure already in CRM.
  3. PricebookEntry records provide contract pricing per buyer group; Commerce Extensions (Winter '24+) can call out to an external pricing engine if needed.
  4. Checkout is a Flow-based process; approval steps can be injected as Flow elements without custom code.
  5. Submitted orders create OrderSummary records directly in the org — accessible to service reps, fulfillment flows, and analytics without any integration.
  6. CRM reports and dashboards show commerce order data alongside pipeline data because they share the same database.

Why not SFCC: SFCC would require a custom integration for every CRM data touchpoint (account entitlement checks, quote-to-order handoff, order history in Service Cloud). Each integration point adds latency, error surface, and maintenance cost. For known-account, CRM-integrated B2B workflows, B2B Commerce on Core is architecturally superior.

Pattern 2: SFCC for High-Volume Anonymous Consumer Storefront

When to use: The storefront serves anonymous or semi-anonymous consumers at high concurrency. Peak traffic during promotions or seasonal events requires infrastructure that scales independently of the Salesforce org's API and compute limits. The team has SFRA/Node.js expertise. The primary integration concern is the payment processor and OMS, not real-time CRM data.

How it works:

  1. SFCC is provisioned with a dedicated Primary Instance Group sized for peak load.
  2. SFRA provides the base storefront; custom cartridges override checkout, promotion, and content behaviors.
  3. The payment processor is integrated via SFCC's payment service framework (cartridge + hook pattern).
  4. Order data is exported to an external OMS or synced to Salesforce Order Management via the Salesforce Connector or custom middleware.
  5. Customer account data stays in SFCC's customer store; a sync to Salesforce Contact records is optional and asynchronous.
  6. SCAPI is used for headless front-end implementations (mobile app, PWA) against the SFCC back end.

Why not B2B Commerce on Core: High-volume anonymous consumer traffic at peak concurrency runs against Salesforce platform governor limits (API request limits, concurrent request caps). SFCC is designed for this traffic pattern with dedicated infrastructure, CDN integration, and purpose-built caching layers that the Salesforce platform does not provide at equivalent cost or scale.

Decision Guidance

SituationRecommended PlatformReason
Buyers are known business accounts with CRM-integrated pricingB2B Commerce on CoreBuyerGroup + EntitlementPolicy model; zero-latency CRM data access
Anonymous consumer traffic at high concurrency (>500 concurrent sessions)SFCCDedicated infrastructure scales independently of Salesforce platform limits
Checkout requires account-level order approvals and spending limitsB2B Commerce on CoreFlow-based checkout supports Approval Process and account-level controls natively
Team has Apex/LWC/Flow skills; no SFRA/Node.js experienceB2B Commerce on CoreCustomization uses existing Salesforce platform skills
Team has SFRA cartridge and Node.js expertiseSFCCCustomization model aligns with team capability
Real-time CRM data required at checkout (account balance, credit limit)B2B Commerce on CoreSame-org data access; no integration latency
External PIM drives product catalog; headless front end is preferredSFCCSCAPI is purpose-built for headless; SFCC catalog import is a mature capability
Custom pricing engine (external service) must be called at checkoutB2B Commerce on Core (Commerce Extensions)Commerce Extensions provide a synchronous callout hook in the checkout flow
Order data must be in Salesforce Order Management in real timeB2B Commerce on CoreOrderSummary is created natively in the same org
Project requires both B2B account-gated and B2C consumer storefrontsEvaluate hybrid: B2B Commerce on Core + SFCC or B2B + D2C on CoreHybrid architectures require explicit data boundary design and separate integration surfaces

Step-by-step instructions for an architect working on this platform decision:

  1. Establish infrastructure constraints first. Determine peak concurrent anonymous session volume and annual order volume. If anonymous consumer traffic exceeds what Salesforce platform API concurrency limits can support at acceptable cost, SFCC becomes the primary candidate. Document this as a hard constraint before evaluating features.
  2. Map CRM data dependencies. List every piece of CRM data the storefront needs at runtime: account credit limits, contract pricing, order history, account entitlements, service case history. If more than two of these require real-time access at checkout, B2B Commerce on Core's same-org data model provides a structural advantage that is difficult to replicate in SFCC without significant middleware investment.
  3. Assess team skills and DevOps maturity. Confirm whether the delivery team has Apex/Flow/LWC capability or SFRA/Node.js/Business Manager capability. Neither platform is easier in the abstract — they favor different skill sets. A team with deep Salesforce platform knowledge will move faster on B2B Commerce on Core; a team with front-end engineering depth will move faster on SFCC.
  4. Evaluate the extensibility model against customization requirements. List every non-standard behavior: custom pricing logic, custom inventory rules, custom tax calculation, custom checkout steps. Map each to the extensibility mechanism on each platform (Commerce Extensions vs. SFRA hooks and cartridges). Identify any requirements that cannot be met by either platform's standard extensibility model.
  5. Design the integration architecture for each option. For B2B Commerce on Core, document what external integrations are needed and how they connect to the org. For SFCC, document the CRM integration surface: what data must flow to/from Salesforce CRM, at what frequency, and through what mechanism (Salesforce Connector, middleware, batch import). The integration complexity delta between the two options is often the deciding factor.
  6. Produce the recommendation with rationale. Document the platform choice with each driving factor cited explicitly. Record capability gaps — what the selected platform does not provide natively — and confirm the team accepts the custom development required to fill those gaps.
  7. Identify the follow-on skills. Once the platform decision is locked, activate the appropriate implementation skill: admin/b2b-commerce-store-setup for B2B Commerce on Core, or admin/b2c-commerce-store-setup for SFCC. If Commerce Extensions are in scope, activate apex/commerce-extension-points.

Review Checklist

Run through these before marking this architectural decision complete:

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

  1. Commerce Extensions do not apply to SFCC — Commerce Extensions (custom pricing, inventory, shipping, and tax service implementations via Apex, introduced Winter '24) are a feature of B2B Commerce and D2C Commerce on Core only. SFCC has its own extensibility model: SFRA hooks, cartridges, and the Business Manager service framework. Recommending or expecting Commerce Extensions to work in an SFCC implementation will result in the entire pricing/tax customization plan failing at build time.
  2. B2B Commerce and B2C Commerce (SFCC) share no objects, APIs, or org data — These are architecturally separate systems. There is no WebStore object in SFCC. There are no BuyerGroup or CommerceEntitlementPolicy records in SFCC. SFCC has no SOQL, no Apex, and no Flow. Any architecture document that refers to Salesforce platform objects (Account, Contact, Product2) as if they are natively available in SFCC is incorrect. Product and customer data must be explicitly imported into SFCC through its catalog and customer import mechanisms.
  3. B2B Commerce checkout is Flow Builder; B2C Commerce checkout is SFRA cartridges — these are not interchangeable — The checkout customization model is fundamentally different. B2B Commerce checkout steps are Flow elements — draggable, declaratively configurable, testable in Flow Builder. SFCC checkout is a cartridge controller chain — Node.js code overriding SFRA base controllers. A team that knows how to customize B2B checkout flows has no transferable skill for SFCC checkout cartridges, and vice versa. Scoping checkout customization without identifying which model applies leads to severely incorrect effort estimates.

Output Artifacts

ArtifactDescription
Platform Architecture ComparisonTable or document comparing B2B Commerce on Core and SFCC across infrastructure, data model, extensibility, integration surface, and team skill requirements
Integration Architecture OutlineDiagram or narrative describing how each platform option connects to external systems (ERP, OMS, PIM, payment processor, Salesforce CRM)
Platform Recommendation with RationaleWritten decision document citing each driving non-functional requirement and how the selected platform addresses it
Capability Gap RegisterList of requirements the selected platform does not cover natively, with disposition for each gap

Package files