B2b Vs B2c Architecture

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:

• Confirm which product family is actually in scope. "Salesforce B2C Commerce" and "D2C Commerce" are not the same product. Salesforce B2C Commerce (also called SFCC or Commerce Cloud) runs on a separate, hosted infrastructure with its own servers, Business Manager admin console, and SFRA (Storefront Reference Architecture) cartridge customization model. D2C Commerce (also called Direct-to-Consumer or Lightning-based B2C Commerce) is a WebStore built on LWR inside the Core Salesforce platform. These are entirely different infrastructure stacks. The research notes for this skill concern B2B Commerce on Core versus SFCC — two platforms that share no objects, no APIs, and no org data.
• Most common wrong assumption: That Commerce Extensions (custom pricing, inventory, shipping, and tax services introduced in Winter '24) are available on both B2B/D2C Commerce and SFCC. Commerce Extensions are a B2B Commerce and D2C Commerce on Core feature only. SFCC has its own separate extensibility model (hooks, pipelines, SFRA cartridges, Commerce APIs). Recommending Commerce Extensions for an SFCC implementation is a category error.
• Non-functional requirements drive the decision. Volume (anonymous concurrent sessions, peak throughput), team skills (Apex/Flow vs. Node.js/cartridges), existing CRM investment, and OMS/ERP integration patterns are the primary architectural levers. The platforms are not interchangeable at scale.

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

• WebStore — the storefront configuration record (one per storefront)
• BuyerGroup + CommerceEntitlementPolicy — account-gated catalog and pricing segmentation
• BuyerAccount / BuyerGroupMember — buyer identity and group membership
• CartItem, CartDeliveryGroup, WebCart — the active shopping cart object graph
• OrderSummary, OrderItemSummary, FulfillmentOrder — order lifecycle objects (Salesforce Order Management)
• Standard PricebookEntry, Product2, ProductCatalog objects — shared with CRM

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:

• Products, catalogs, inventory, promotions, content assets, and customer data are stored in SFCC's proprietary database.
• SFCC customer records (profiles, addresses, order history) are not Salesforce Contact or Account records. They exist in SFCC's customer data store.
• Order data is stored in SFCC and can be exported or synced to an external OMS, but SFCC does not natively share OrderSummary objects with Salesforce Order Management.
• Product data typically originates in a PIM and is imported into both SFCC and Salesforce CRM independently (or via a shared PIM integration).

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:

SFCC — extensibility paths:

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:

• Exposes the Salesforce Connect API (REST/SOAP) for all standard and custom objects.
• Exposes the B2B Commerce Connect REST API (also called Commerce Webstore APIs) for storefront operations: product search, cart management, checkout, order history.
• Exposes the Salesforce Order Management APIs for order lifecycle if OSM is provisioned.
• External integrations (payment processors, tax engines, ERP) connect to the org the same way any other integration does — via Connected App, OAuth, or Named Credential.
• Commerce Extensions let the org call out to external pricing, tax, or inventory services and return results into the checkout flow synchronously.

SFCC:

• Exposes the Open Commerce API (OCAPI) — the legacy REST API suite for shop operations, data management, and meta operations.
• Exposes the Shopper Commerce API (SCAPI) — the modern, performance-optimized REST API for headless commerce implementations.
• Exposes the Management API for Business Manager automation (catalog imports, code deployment, site preferences).
• SFCC integrates with payment processors, tax engines, and shipping providers through its own cartridge-based integration framework and the SFCC payment/service frameworks.
• Salesforce CRM integration requires either the Salesforce Connector for B2C Commerce (a managed solution) or a custom middleware pattern. There is no native object sharing.

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

Recommended Workflow

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:

• Peak concurrent session volume and annual order volume are documented
• CRM data dependencies at checkout runtime are enumerated
• Team skills (Salesforce platform vs. SFRA/Node.js) are assessed and documented
• Extensibility requirements are mapped to each platform's extension model
• Integration architecture is sketched for both options (even the rejected one)
• Commerce Extensions scope is clarified — B2B/D2C on Core only, not SFCC
• The recommended platform is documented with explicit rationale per non-functional requirement
• Capability gaps for the selected platform are listed with a disposition (accept, custom-build, or third-party)
• Follow-on implementation skills are identified

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

Related Skills

• admin/b2b-vs-b2c-requirements — use upstream of this skill for buyer-journey and requirements-level platform selection before architectural evaluation
• admin/b2b-commerce-store-setup — use after selecting B2B Commerce on Core; covers WebStore creation, BuyerGroup and entitlement policy setup, and buyer contact configuration
• admin/b2c-commerce-store-setup — use after selecting SFCC; covers Business Manager configuration, SFRA setup, and storefront activation
• apex/commerce-extension-points — use when B2B Commerce on Core is selected and custom pricing, inventory, shipping, or tax logic is required
• integration/salesforce-b2c-commerce-connector — use when SFCC is selected and a Salesforce CRM integration is required