Free B2B-Commerce-Developer Practice Test Questions 2026

Explanation:

In Salesforce Lightning Web Components (LWCs), including those used in B2B Commerce storefronts (LWR sites or Experience Builder), best practice for designing public API properties (decorated with @api) is to use independent, simple, primitive-typed properties rather than complex nested objects or a single large object.

Key reasons include:

Reactivity and Change Detection
LWCs use a reactive system that efficiently tracks changes to primitive values such as String, Number, and Boolean. Deep changes inside complex nested objects may not reliably trigger re-renders unless additional steps are taken, such as reassigning the entire object. Using independent primitive properties avoids these issues.

Configurability in Experience Builder
When a custom LWC is added to a B2B Commerce page through Experience Builder, each @api property appears as a separate configurable field in the Properties panel. Simple data types provide a clean and intuitive configuration experience, while complex objects are difficult or impossible to configure in the UI.

Reusability and Maintainability
Small, focused properties follow the principle of least surprise and make components easier to reuse, test, and maintain over time.

Salesforce Guidelines
Official Salesforce LWC documentation recommends declaring public properties as simple types whenever possible. More complex data should be fetched or managed internally using @wire or imperative Apex calls.

❌ Why not the other options?

A. A few properties that contain sets (objects) of data
This approach encourages complex objects, which can negatively impact reactivity and make Experience Builder configuration cumbersome.

B. One property that contains all data in one set (object)
Using a single large object is an anti-pattern in LWC design. It reduces flexibility, complicates reactivity tracking, and makes the component harder to configure and extend.

C. A single property object that contains sets (objects) of data
This option has the same drawbacks as option B and still promotes a monolithic object instead of granular, primitive properties.

📚 References
Salesforce LWC Developer Guide: Fields, Properties, and Attributes
Trailhead: Create Custom Salesforce Commerce Components

Explanation:

To expose a public property in a Lightning Web Component (LWC), you must use the @api decorator. This marks the property as public and reactive, allowing it to be set by a parent component or configured through the Experience Builder property editor.

@api (D)
This decorator transforms a private field into a public property. It defines the public API of the component and enables data to flow from parent components or page configuration into the LWC.

Reactivity
When a property decorated with @api changes, the component automatically rerenders to reflect the updated value, following the LWC reactive programming model.

❌ Why the others are incorrect

A. @property
This is not a valid decorator in Lightning Web Components.

B. @track
This decorator is used to make private properties reactive, particularly for changes within objects or arrays. It does not expose a property publicly and cannot be configured in Experience Builder.

C. @public
Although the intent is to make a property public, @public is not a supported decorator in the LWC framework. The correct and supported decorator is @api.

Developer Authorization Steps (Contextual Note)

When authorizing a new org for development, a developer typically uses one of the following approaches:

Use the Salesforce CLI command: sf org login web
Alternatively, use the VS Code Salesforce Extension Pack and select SFDX: Authorize an Org from the Command Palette.

Explanation:

When developing Lightning Web Components for a B2B Commerce Aura storefront, cart data is exposed through the ICart interface.

The Totals object within ICart contains aggregated values such as subtotal, shipping, tax, and the grand total.

ICart.Totals.grandTotal provides the final cart amount, including shipping and tax, expressed in the currency of the cart.

Let’s break down the options:

A. {!Cart.Details.grandTotal}
Incorrect. Cart.Details contains metadata and descriptive information and does not expose cart totals.

B. {ICart.Totals.grandTotal}
✅ Correct. This is the proper way to access the cart’s grand total, including shipping and tax.

C. {ICart.Details.Fields.grandTotal}
Incorrect. Details.Fields is not a valid path for accessing total values.

D. {!Cart.Fields.grandTotal}
Incorrect. Cart.Fields does not expose totals, making this syntax invalid for cart totals.

📚 Reference
Salesforce B2B Commerce Developer Guide: Cart Interface (ICart) and Totals object documentation

Explanation:

Why "D" is Correct
In Lightning Web Components (LWC), Salesforce provides scoped modules to access global information about the current user, organization, or site.

The @salesforce/community module is specifically designed to provide context for the Experience Cloud site (formerly known as a Community) where the component is running.

Importing Id from this module returns the Network ID, which is the unique 18-character identifier of the site. This value is commonly used in B2B Commerce to ensure that Apex methods or wire services retrieve data for the correct storefront.

❌ Why Others are Incorrect

A. @salesforce/network/Id
Although Network is the underlying object name for an Experience Cloud site, this is not a valid scoped module syntax for LWC imports.

B. @salesforce/experience/Id
Despite the rebranding from Communities to Experiences, Salesforce maintains the community naming convention for backward compatibility. This scoped module does not exist.

C. @salesforce/site/Id
This is a common misconception. @salesforce/site is not a supported scoped module for retrieving the current Experience Cloud site ID.

📚 Reference
Salesforce LWC Developer Guide: Import References to Salesforce Objects and Fields – Scoped Modules
Salesforce Help: Get the ID of the Current Experience Cloud Site

Explanation:

In Salesforce B2B Commerce (ccrz), the Checkout flow is a highly configurable process that controls how many steps a buyer sees (for example: Shipping → Payment → Review). Modifying the number of checkout steps is not done in a single place—it requires coordination between templates, configuration settings, and cache activation.

Let’s walk through why A, C, and E are required and why the others are not.

✅ A. Perform a template override on the Checkout page
The checkout experience in B2B Commerce is rendered using Visualforce templates (Aura storefront architecture).
If you want to change the number of steps, you must override the default checkout template so Salesforce knows to use your custom step layout instead of the standard one.

Without a template override:
- The default checkout step sequence is enforced
- Any configuration changes will be ignored at the UI level

Template overrides are therefore a mandatory step when changing checkout structure.

✅ C. Build and activate a new configuration cache setting via CC Admin
B2B Commerce uses a configuration cache to improve performance.
When you change checkout-related configuration values, those changes do not take effect until the configuration cache is rebuilt and activated in CC Admin.

This step:
- Ensures new checkout settings are recognized
- Prevents storefronts from using stale configuration values
- Is required for any checkout flow customization

On the exam, anything involving checkout configuration almost always implies cache rebuild and activation.

✅ E. Set CO.overrideFlow to TRUE
The configuration setting CO.overrideFlow explicitly tells B2B Commerce to:
- Ignore the default checkout flow
- Use a custom-defined flow instead

If this value is not set to TRUE, Salesforce will always fall back to the standard checkout step sequence—even if templates and other settings are changed.

This setting is essential when modifying the number of checkout steps.

❌ Why the other options are incorrect

❌ B. Add a page include to the checkout page
- Page includes are used to inject UI components
- They do not control checkout flow logic or step sequencing
- Useful for content, not structural checkout changes

❌ D. Set CO.useDef to TRUE
- CO.useDef forces the default checkout behavior
- Setting it to TRUE would actually prevent customization
- This is the opposite of what’s needed when modifying steps

📚 Salesforce References
Salesforce B2B Commerce Developer Guide
Checkout Configuration and Flow Overrides
Salesforce Help: Customize the B2B Commerce Checkout Flow
Trailhead: Extend and Customize B2B Commerce Checkout

Explanation

Why "B" and "D" are Correct
The lightning/platformResourceLoader module provides two specific functions to load static resources into the browser:

loadScript(this, resourceName) (B): This is the standard method used to load a JavaScript file. It returns a Promise, allowing you to ensure the library is fully loaded before you attempt to initialize it in your component's renderedCallback().

loadStyle(this, resourceName) (D): This is the method used to load a CSS file. Like loadScript, it returns a Promise and applies the styles globally within the component's scope (respecting Shadow DOM boundaries).

Why Others are Incorrect

A. loadClientScript: This is not a valid method in the Salesforce LWC framework. While "client-side script" is a common term, the API naming convention is simply loadScript.

C. loadCss: This is a common point of confusion. While the files being loaded are CSS files, the actual method name provided by the Salesforce module is loadStyle.

Reference
Salesforce LWC Developer Guide: Use Third-Party JavaScript Libraries.
Salesforce B2B Commerce Developer Guide: Styling and Scripting Custom Storefront Components.

Explanation:

In Salesforce Experience Cloud, components fall into two broad categories:
- General-purpose Experience components that can be used across many templates and use cases
- B2B Commerce–specific components that are tightly coupled to the B2B Commerce data model, APIs, and storefront context

The key to this question is the phrase:
“can be used in other Salesforce Experience templates outside of B2B Commerce”
Among the options, CMS Collection is the only component that meets this criterion.

✅ Why CMS Collection is correct
The CMS Collection component is part of Salesforce CMS (Content Management System) and is designed to be template-agnostic. It allows administrators and developers to:

Display curated collections of content such as:
- Images
- Text
- Rich media
- Documents

Reuse the same content across:
- B2B Commerce storefronts
- Customer Service portals
- Partner portals
- Custom Experience Cloud sites

Because CMS is a core Experience Cloud feature, the CMS Collection component works independently of B2B Commerce. It does not rely on commerce-specific objects like Cart, Product, Pricing, or Buyer Account. This makes it reusable across virtually all Experience templates.

This is exactly what the question is testing: identifying a component that is not locked into B2B Commerce.

❌ Why the other options are incorrect

❌ A. Quick Order
- Exclusively a B2B Commerce component
- Depends on:
- Product catalogs
- Pricing models
- Buyer context
- Will not function outside a B2B Commerce storefront

❌ C. Product Detail Data
- Tightly bound to B2B Commerce product APIs
- Requires:
- Commerce product context
- Active storefront
- Not usable in non-commerce Experience templates

❌ D. Results Layout
- Specifically designed for B2B Commerce search and category results
- Depends on:
- Commerce search indexes
- Product result data
- Cannot operate outside B2B Commerce

📚 References
Salesforce Help: Salesforce CMS Overview
Trailhead: Deliver Content with Salesforce CMS
Salesforce B2B Commerce Developer Guide: Storefront Components vs CMS Components

Explanation:

Core Concept: This question tests the knowledge of the specific, pluggable service interface that must be implemented to inject custom pricing logic into the B2B Commerce checkout flow. This is a key extensibility point.

Why This Answer is Correct:

The sfdc_checkout.PriceCalculations interface is the contract defined by the B2B Commerce framework for custom price adjustment services. When a developer creates an Apex class that implements this interface, they are required to provide an implementation for its method(s), such as calculatePrices. The checkout flow will then invoke this custom class to apply pricing adjustments (like custom discounts, surcharges, or complex tiered pricing) to the cart and its line items.

Why the Other Answers are Incorrect:

A. sfdc_commerce.CartPriceCalculations: This is not a standard B2B Commerce interface. The correct namespace is sfdc_checkout.

B. sfdc_commerce.PriceCalculations: This uses the wrong namespace (sfdc_commerce instead of sfdc_checkout).

D. sfdc_checkout.CartPriceCalculations: This interface name does not exist. The correct interface name is PriceCalculations.

Explanation:

When a developer configures and enables a tax integration (e.g., third-party tax provider via Cart Calculate API, RegisteredExternalService, or Salesforce Tax Solution) for a B2B Commerce store, the system replaces the default tax calculation logic with the new integrated service.

During the checkout flow (and often during cart calculations via CCA), the platform performs a fresh tax recalculation:

- Any previously calculated tax entries (e.g., from default Salesforce tax logic, manual gross tax, or a prior integration) are deleted from the Cart object (specifically from related CartTax records or tax adjustment lines).
- The new tax integration computes and applies new tax entries based on current cart state, address, items, and the external provider's response.
- This ensures consistency and prevents conflicts or stale data from old calculations persisting in the cart.

This behavior is part of how the Cart Calculate API (CCA) and checkout integrations work: when a new tax calculator is active, it overrides and clears prior tax data before inserting updated values.

Why not the other options?

A. Ignored during recalculation
Incorrect — previous taxes are not merely ignored; they are actively removed to avoid duplication or inconsistency with the new integration's results.

B. Saved prior to recalculation
Incorrect — There is no mechanism to preserve or archive old tax entries before recalculation in standard tax integration setup. They are replaced, not backed up.

D. Modified with the new tax calculation
Incorrect — Old entries are not updated in place; the previous tax records are deleted, and entirely new CartTax or adjustment records are created based on the integration's output.

References:
Salesforce Developer Docs: Cart Calculate API — When tax integrations are configured (via sfdc_checkout.TaxCalculations or external services), the system recalculates taxes fully, replacing existing tax data (implied by how calculators override and populate adjustments).

Explanation:

In Lightning Web Components (LWCs), the connectedCallback() lifecycle hook is invoked when the component is inserted into the DOM. This is the right place to:
- Initialize data.
- Set up event listeners.
- Perform actions that depend on the component being rendered.

Let’s break down the options:

A. It performs actions when a network request is made → ❌ Incorrect. Network requests are not tied to lifecycle hooks; they’re triggered explicitly in code.
B. It performs actions when a component makes a call to a Connect API → ❌ Incorrect. API calls are developer-driven, not lifecycle-driven.
C. It performs actions when a component is removed from the DOM → ❌ Incorrect. That’s handled by the disconnectedCallback() lifecycle hook.
D. It performs actions when a component is added to the DOM → ✅ Correct. This is the purpose of connectedCallback().

Reference
Salesforce Developer Guide: Lightning Web Components Lifecycle Hooks

Explanation:

Core Concept: This question tests understanding of the fundamental architectural design pattern that Lightning Web Components (LWC) are built upon, which is central to modern front-end development.

Why This Answer is Correct:

Composition is the core pattern of building complex UIs by combining smaller, reusable, and single-responsibility components into larger ones. In LWC, you build a parent component that contains and orchestrates several child components in its template. This pattern promotes:

- Reusability: Small components (like a button, an input field, a product tile) can be used in many different contexts.
- Maintainability: Each component manages its own logic and styling, making the codebase easier to understand and modify.
- Encapsulation: Components communicate through a well-defined public API (@api properties and events), hiding internal implementation details.

Why the Other Answers are Incorrect:

B. Inventory: This is not a recognized software design pattern in the context of UI component architecture. It's a distractor related to commerce terminology.
C. Juggling: This is not a software design pattern.
D. Normalization: This is a data modeling pattern (often used in database design to reduce redundancy) or a process for standardizing data structures. While data normalization might occur in the backend services an LWC calls, it is not a key pattern for building the components themselves.

Key References / Considerations:

- LWC & Modern Web Standards: Composition is a key principle of the web components standard that LWC implements. You see this in the HTML-like syntax where a custom tag represents a component.

- Example in B2B Commerce:
A product-details-page component (parent) might be composed of:
- A product-media-viewer component.
- A product-description component.
- A product-attributes component.
- An add-to-cart component.
Each of these is a standalone, reusable LWC.

- Contrast with Inheritance: Composition is often favored over deep class inheritance for UI components because it offers more flexibility and reduces tight coupling.

This pattern is not just for LWC but is a fundamental concept in modern front-end frameworks (React, Vue, Angular) and is critical knowledge for any Salesforce developer building dynamic user interfaces.

Explanation

Why "B" is Correct
The cc_hk_Menu (Menu Hook) is the specific extension point provided by the B2B Commerce Classic API for altering the navigation menu.

- Post-processing: Because menu items are heavily cached to ensure fast page loads, the system retrieves the list of items from the cache first. The "post-process" method allows you to intercept that list after it has been retrieved but before it is rendered to the user.

- User Customization: Inside this hook, you can write Apex logic to check the current user’s permissions, Account ID, or custom attributes and programmatically remove or add items to the menu list based on those criteria.

Why Others are Incorrect

A & D (cc_hk_Category): The Category Hook is used for modifying product category logic, such as the Category Tree or product assignments. While menus often contain categories, the menu itself is a distinct entity managed by the Menu Hook.
C (Pre-process): Pre-processing occurs before data is cached or retrieved. If you filtered menu items here, you would be filtering what gets stored in the global cache, which would affect all users rather than providing a personalized experience for different users.

Reference
Salesforce B2B Commerce Developer Guide: Menu Hook (cc_hk_Menu).
Salesforce Help: Customize the Storefront Menu via Apex Extensions.