B2B-Commerce-Developer Practice Test Questions (2026)

Explanation:

In Salesforce B2B Commerce (ccrz), when you write an Apex @RemoteAction method, you must explicitly initialize the call context so that B2B Commerce APIs (pricing, cart, buyer info, locale, etc.) work correctly.

The required static method is:
ccrz.cc_CallContext.initCallContext(remoteActionContext);

This method:
Takes an instance of ccrz.cc_RemoteActionContext

Initializes ccrz.cc_CallContext with:
Buyer Account
Effective Account
User context
Locale and currency

Enables the method to correctly return a ccrz.cc_RemoteActionResult
This is the only valid and supported method for initializing the call context in an Apex @RemoteAction.

❌ Why the other options are incorrect

A. init(ccrz.cc_RemoteActionContext)
❌ No such method exists in ccrz.cc_CallContext.
C. initRemoteActionContext(ccrz.cc_RemoteActionContext)
❌ Sounds plausible, but Salesforce does not define this method.
D. initializeCallContext(ccrz.cc_RemoteActionContext)
❌ Not a valid API method in B2B Commerce.

Salesforce exam questions often include “reasonable-sounding” method names—this is a classic trap.

📚References
Salesforce Help: B2B Commerce Apex API (ccrz namespace)
Trailhead: B2B Commerce for Developers – Remote Actions
Salesforce B2B Commerce Developer Guide
Section: Using @RemoteAction with ccrz.cc_CallContext

Explanation:

Custom labels are text values that can be translated into any language that Salesforce supports. They are useful for displaying language-specific text in Lightning Web Components (LWC).

To use custom labels in an LWC, the developer must create them in the Setup menu and assign them a value (and translations, if needed). Then, the developer can import them into the LWC using the @salesforce/label scoped module.

For example:
If a custom label is named welcomeHeader, it can be imported as follows:
import welcomeHeader from '@salesforce/label/c.welcomeHeader';

The imported label can then be used in either the HTML template or the JavaScript file of the LWC.

The custom label automatically displays the translated value based on the user’s language preference. The developer can also use the lightning-formatted-text component to render the custom label value with HTML formatting when needed.

❌ Why the other options are incorrect

A. Importing static resources for the text values
Static resources are not recommended for translating text in LWCs. They are meant for files such as images, CSS, or JavaScript and do not support automatic translation based on the user’s language preference.

B. Using a CustomLabel XML file inside the LWC
This is not valid. Custom labels are created and managed in the Setup menu, not stored in XML files within an LWC. They must be imported using the @salesforce/label scoped module.

D. Creating a Custom Metadata object and querying it from the LWC
Custom Metadata is intended for configuration data, not for language-specific UI text. It does not support automatic translations and would require Apex and wire services, adding unnecessary complexity.

📚 References
Use Custom Labels in Lightning Web Components
Custom Labels
Internationalizing Your Lightning Web Component (LWC)

Explanation:

To bulk-create Product data translations (specifically for B2B Commerce on Lightning), records are inserted into the Product2DataTranslation object (or related translation objects). The following permissions are required to perform this operation successfully:

View Setup and Configuration
This is the baseline permission needed to access backend configuration, schemas, and APIs so that tools like Data Loader can interact with translation-related objects.

A. Import Custom Objects
Even though Products are standard objects, translation data is stored in specialized translation objects. Data Loader requires this permission to allow bulk INSERT or UPDATE operations through the API on these related objects.

D. Manage Translations
This is a core Salesforce platform permission. Without it, a user cannot create or modify translation records. It enables access to Translation Workbench data and allows bulk updates of localized content using tools such as Data Loader or Workbench.

❌ Why the other options are incorrect

B. B2B Commerce Super User
This permission is intended for storefront functionality, such as managing users or orders on the front end. It does not grant system-level or API permissions required for bulk translation data imports.

C. Create and set up Experiences
This permission allows a user to build and configure sites using Experience Builder. It does not provide database-level access or rights to import or manage translation records.

📚 References
Salesforce Help: Import Translated Data for B2B Commerce
Data Loader Guide: Requirements for interacting with Metadata and Translation objects

Explanation:

Core Concept:
This question tests the fundamental, required workflow for developing custom Lightning Web Components (LWCs) in the modern Salesforce development lifecycle, which is centered around Salesforce DX (SFDX) and source-driven development.

Why These Answers are Correct:

B. Authorize an org for an SFDX project
This is the first critical step. SFDX projects are developed locally using VS Code and the Salesforce CLI. To retrieve metadata from or deploy metadata to a Salesforce org (scratch, sandbox, or production), you must authorize that org using commands such as sf org login web. This establishes a secure connection between the local project and the target environment.

D. Deploy a custom component
This is the essential final step that makes the component usable. After creating and testing the LWC locally, its source files (.js, .html, .js-meta.xml, etc.) must be deployed to a Salesforce org. This is typically done using sf project deploy start or by pushing changes to a scratch org. Until deployment, the component cannot be used in a storefront or Lightning application.

❌ Why the Other Answers are Incorrect:

A. Create an Apex class
Creating an Apex class is not required to build an LWC. While many LWCs—especially in B2B Commerce—use Apex for server-side logic, a component can be purely presentational or rely on Lightning Data Service. Therefore, this step is optional.

C. Clone an LWC
Cloning an existing LWC is a possible development technique but not a mandatory step. Developers commonly generate new components from scratch using sf generate component. Cloning is situational, not required.

Key References / Considerations:

Modern Toolchain
The B2B Commerce Developer exam assumes familiarity with the SFDX development model rather than the legacy org-based development approach.

Typical LWC Creation Workflow:
Set up a local SFDX project (sf generate project).
Authorize a target org (sf org login web).
Create the LWC component files (sf generate component).
Code and test the component locally or in a scratch org.
Deploy the component (sf project deploy start).

For B2B Commerce Specifically:
Custom LWCs are used to extend the LWR-based storefront. They must be deployed to the org and then added to an Experience Cloud site or registered within the B2B Commerce storefront. Deployment is a non-negotiable step.

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.