Salesforce B2B Commerce: identify the storefront architecture before integration

A company commissions a new shipping calculation for Salesforce B2B Commerce, but the contractor estimates the work based on experience with a different storefront. Once work begins, it turns out that the cart components, navigation and checkout mechanism are different here. To avoid buying an integration for the wrong architecture, first confirm the product, storefront runtime and existing extension points. The diagnostic process below should produce a verified architecture record for the specific store.

This guide is for the e-commerce manager and technical owner of an existing store: how to give a contractor accurate inputs and separate connecting a service from rebuilding the storefront.

1. Identify the product, not the name in the presentation

The label Salesforce or Commerce Cloud does not describe the technical foundation. Salesforce has different Commerce solutions, including B2B and B2C; shared branding does not make their development models interchangeable. Ask the administrator to reconcile the purchased products with the store actually configured, rather than guessing from the type of buyer.

A separate website may send contacts and orders to Salesforce CRM while running its cart and catalog on another platform. That is a CRM integration, not proof of Salesforce B2B Commerce. Selling to dealers does not determine the product either: the B2B business model and the software product name are different things. Record where the cart is created, who calculates the total and which system accepts the order.

Collect the Salesforce organization name, store identifier, environment URLs, product confirmation and repository link. Do not include passwords, tokens or buyer data. Leave discrepancies between documents and configuration open until they have been reviewed jointly.

2. Establish the storefront runtime from its configuration

Runtime is the environment in which the store interface operates. Salesforce documents Lightning Web Runtime (LWR) and Aura templates for B2B storefronts. B2B LWR is recommended for new stores. If the organization was enabled for Commerce before Spring ’23, a B2B Aura template may also be available. This is a condition for template availability, not a way to identify a particular site's runtime by its age.

Check the template and components together

Have the administrator show the template for the specific store in the site management tools, and the developer show the corresponding project and components. LWC stands for Lightning Web Components, the interface component model; LWR is their runtime environment. Having LWC in a repository does not, by itself, prove LWR: Salesforce's migration scenario also describes reusing child LWC from an Aura storefront.

A screenshot, domain or loading speed is weak evidence. For each store separately, record the verification date, template, source of confirmation and responsible person.

A separate interface needs a second architecture record

If the buyer uses a separate frontend, establish which Commerce backend sits behind it, where the interface is deployed and how it retrieves data. Headless describes the separation of interface and commerce system, not a product name or a compatibility guarantee. Check both parts and any intermediate server. For context, see the article on when a headless store architecture is justified; the task here is narrower: to identify an already installed solution.

3. Build a table of evidence and implications

A storefront architecture record connects evidence to integration decisions. Saying “we have Lightning” does not explain which code triggers the calculation. The table is a diagnostic acceptance form, not an automatic platform identifier.

Add a status of “confirmed,” “hypothesis” or “not established” and an evidence link for every row. If the runtime or checkout mechanism is unknown, the next stage is investigation, not a fixed estimate for a connector.

4. Locate the calculation before choosing a connector

In Salesforce documentation, the checkout integration mechanisms for B2B LWR differ from Aura checkout subflows. Salesforce also recommends Commerce extensions for more targeted changes instead of the older checkout integrations framework, which remains supported. This is not an instruction to rewrite a working store immediately: first establish what it uses and what the new service requires.

Map one request: buyer action → storefront component → server-side calculation → external service → result in the cart. For each arrow, identify the owner, data transmitted and error behavior. Clarify whether shipping is recalculated after an address change, when the result becomes stale and whether a delayed response can overwrite a newer selection. These are questions for checking your implementation, not universal Salesforce characteristics.

Describe the exchange contract: product identifiers, units of measure, currency, address, company context and request version. Establish the source of each value. If ERP and Commerce interpret packaging differently, changing a button will not fix the calculation.

5. Do not disguise an Aura → LWR migration as an integration

The official plan for migrating a B2B store from Aura to LWR involves a new store using the appropriate template, replacing Aura components with LWC, transferring configuration and checking before publication. In particular, the cart changes from a record page to a named page, so links and navigation components need attention. This is a specific dependency easily missed in an estimate for “just connecting shipping.”

Salesforce also describes a separate project space to preserve the existing Aura storefront while work proceeds. Turn this into your own parallel validation plan: what remains available, where the new store is tested and who authorizes the switch. Preserving the old storefront does not mean order rollback is ready: data movement after the switch needs a separate plan.

Hypothetical example: the discount works, shipping does not

A hypothetical distributor has an Aura storefront and a custom warehouse selector in the cart. The team moves to LWR and connects a carrier at the same time. The new page retains the negotiated price, but the “go to cart” button follows the old route, and the selected warehouse is missing from the shipping request. This is a fictional training scenario, not a GL.ua case study or a claim about a standard platform defect.

First check navigation and warehouse transmission, then the carrier's response and how it is displayed. The address, warehouse, products and buyer context must correspond to the same request. A correct price does not prove that the rest of checkout is correct.

6. Run a prelaunch check along one complete journey

Prelaunch integration testing must reproduce the identified product and runtime, not the contractor's demo store. Prepare test companies with different permissions and a reference product set without real personal data. For each test, record the expected result, actual result and person responsible for resolving any deviation.

1. Reconcile the architecture record with the test environment: product, template, custom code versions and integration configuration. Noncomparable environments do not prove readiness.
2. Log in as buyers from different companies. Check the available catalog and price, then the corresponding context in the server-side calculation; another company's terms must not leak between sessions.
3. Follow product → cart → checkout. Change the quantity, address and warehouse, if applicable. Confirm that the calculation updates for the current dataset.
4. Simulate an external service delay, outage and invalid response in a controlled environment. Check the buyer message, support diagnostics and permitted next action.
5. Test repeated clicks and resubmission after a failure. Confirm from the logs that the integration did not create a duplicate order or issue a false confirmation.
6. Follow the journey on desktop and mobile, including a direct cart link and returning from checkout. For a migration, check changed routes separately.
7. Reconcile the order total in Commerce and the accounting system, and rehearse the switch and stop procedure. Authorize launch only after critical deviations are resolved.

The broader process is described in the article on online store acceptance and rollback. Here the key evidence is the connection between the test and the actual architecture.

7. Assess dependencies, cost and responsibilities

The timeline depends on access to configuration and code, test environment readiness, service documentation, custom components and the need for runtime migration. Until diagnosis is complete, estimate stages with explicit unknowns. Agree on the launch calendar after testing the highest-risk scenario.

Separate discovery, a prototype of the critical calculation, interface changes, server-side extension, data mapping, tests, switching and support in the budget. Check licenses, third-party service terms, environments and operating expenses separately. An Aura → LWR migration, if needed, has its own scope; do not hide it in connector costs. There is no universal price or guaranteed timeline without these inputs.

The main risks are misidentifying the product, incomplete code inventory, company context leakage and stale calculation data. Assign an owner and a stop criterion to each. Without access to the implementation and a reproducible test checkout, adding a service only increases uncertainty.

The diagnostic outcome is not a requirement to change platforms, but a sufficient basis for choosing between a local enhancement, a separate storefront migration and a wider redesign. To discuss web architecture and a possible Drupal-oriented alternative, submit the store's architecture record and reference scenario through the GL.ua (Glyanec) website development page. This is a concrete starting point for a consultation, not a promise of a Salesforce implementation or an automatic migration.