Free B2B-Commerce-Developer Practice Test Questions 2026

A.   {{#ifStoreSetting 'Field__c'}} ... {{/ifStoreSetting}}

Explanation:

In Salesforce B2B Commerce (Classic, CCRZ framework), Handlebars helpers are used to control conditional rendering of markup in pages and components. One of the most common helpers is ifStoreSetting, which evaluates a store setting and conditionally toggles the display of a block of markup.

{{#ifStoreSetting 'Field__c'}} ... {{/ifStoreSetting}}
This helper checks whether a given store setting (e.g., a custom field or configuration flag) is enabled or has a truthy value. If so, the enclosed markup is rendered; otherwise, it is hidden. This is the standard way to toggle UI elements based on store configuration.

Why the other options are incorrect:
B. {{#ifSetting 'Page.cfg'}} ... {{/ifSetting}} → Not a valid helper in B2B Commerce.
C. {{#ifConfig 'Field__c'}} ... {{/ifConfig}} → Incorrect helper; configuration values are not toggled this way.
D. {{#ifDisplay 'Page.cfg'}} ... {{/ifDisplay}} → Not a supported helper; display toggling is handled via ifStoreSetting.

✅ In summary:
The ifStoreSetting helper is the correct expression used in Salesforce B2B Commerce to toggle the display of markup blocks based on store settings.

D.   ccrz.ccAPI.SZ_SOBJECT

Explanation:

This question tests knowledge of a specific, advanced API flag in the legacy CCRZ (Visualforce) B2B Commerce Global APIs.

Purpose of the Flag:
The ccrz.ccAPI.SZ_SOBJECT flag is a sizing/formatting flag that, when passed as true in the input data map to a Global API call (like ccrz.ccAPIProduct.fetch()), instructs the API to return the raw sObject records (e.g., Product2, ccrz__E_ProductMedia__c) in the result set, in addition to the standard processed data beans.

Why it's correct:
The flag's name clearly indicates its function (SOBJECT). It is a static constant within the ccrz.ccAPI class. The question explicitly asks for the flag that allows sObjects to be returned when set to true.

Why the other options are incorrect:
A. ccrz.ccAPISizing.SKIPTRZ: This is a distractor. SKIPTRZ might be a valid flag related to skipping transactional logic, but it is not the flag for returning sObjects. The namespace ccAPISizing is also incorrect for this specific flag.

B. ccrz.ccAPISizing.SOBJECT: This has the right suffix (SOBJECT) but the wrong class. The flag is defined in ccrz.ccAPI, not ccrz.ccAPISizing.

C. ccrz.ccAPI.SZ_SKIPTRZ: This flag likely exists for skipping transactional wrappers, but it is not the flag for returning sObjects. The question asks for the flag that specifically enables sObject returns.

Key Reference/Concept:
Global API Input Parameters: The CCRZ Global APIs accept a Map<String, Object> of input parameters. These include sizing flags that control the shape and depth of the returned data.

Common Sizing/Conversion Flags:
- ccrz.ccAPI.SZ_SOBJECT: Return raw sObjects.
- ccrz.ccAPI.SZ_ASSC: Global association sizing block (as discussed in a previous question).
- ccrz.ccAPI.SZ_DATA: Return processed data beans (the default).

Use Case: A developer would use SZ_SOBJECT=true when they need to directly access sObject fields that are not exposed in the standard bean structures, or when performing complex, low-level operations that require the database records.

Exam Takeaway:
This is a very specific piece of API knowledge. Remember that ccrz.ccAPI.SZ_SOBJECT is the flag to request raw sObject data from the Global APIs. The pattern is ccrz.ccAPI.SZ_* for these types of control flags.

A.   Calling in with an API version set to lower than 1 will result in an exceptional case where the exception classccrz.BelowMinAPIVersionException will be returned tocallers.

D.   Minimum API_VERSION is 1 and the Maximum API version follows the releases. E.g. The maximum was 4 as of Salesforce B2B Commerce Release-4.5, 5 as of Salesforce B2B CommerceRelease 4.6, etc.

E.   Calling in with an API version set to more than current maximum will result in exception case where the exception class ccrz.ExceedsMaxAPIVersionException will be returned to callers.

Explanation:

In Salesforce B2B Commerce for Visualforce (the classic CloudCraze-based framework), the Global API (classes like ccrz.ccApiCart, ccrz.ccApiProduct, etc.) supports versioning via the ccrz.ccAPI.API_VERSION key in the input map passed to API methods. This versioning ensures backward compatibility and controlled evolution of input/output structures, method signatures, and behavior across managed package releases.

A is true: If you pass an API_VERSION < 1 (e.g., 0 or negative), the API throws ccrz.BelowMinAPIVersionException immediately. This enforces a hard minimum to prevent invalid calls.

D is true: The minimum supported API_VERSION is 1. The maximum is tied to the installed B2B Commerce managed package version (release number). For example, Release 4.5 supported up to version 4, Release 4.6 up to 5, and so on—each major release increments the max version to introduce breaking changes or new features while allowing older versions for compatibility.

E is true: If you pass an API_VERSION higher than the current maximum supported by the installed package (e.g., calling with version 6 on a package that maxes at 5), the API throws ccrz.ExceedsMaxAPIVersionException. This prevents calls to "future" versions that don't exist yet.

Why not the others?
B. There is no need to pass API_VERSION to the Global APIs: Incorrect. While some convenience overloads or defaults may exist in certain contexts, the standard and documented requirement for Global API calls is to explicitly include ccrz.ccAPI.API_VERSION in the input map (often set to ccrz.ccAPI.CURRENT_VERSION for latest behavior). The API does not auto-infer from package version alone—explicit versioning is required for reliable, forward-compatible calls.

C. The API version is scoped at the Class API level and NOT at the method level: Incorrect. Versioning is applied per-call (method level) via the input map passed to each Global API method invocation. It is not scoped statically at the class level (e.g., no class-level version declaration). Different calls can use different versions in the same transaction.

Reference:
- B2B Commerce for Visualforce Developer Guide (legacy sections): Describes ccrz.ccAPI.API_VERSION requirement in input maps, minimum=1, max tied to release (e.g., increments per major release), and exceptions ccrz.BelowMinAPIVersionException / ccrz.ExceedsMaxAPIVersionException for out-of-range values.
- Release Notes (various versions, e.g., Spring '20, Winter '21+): Mention API compatibility fixes tied to versions.

B.   "__ccrz"

Explanation:

In Salesforce B2B Commerce, when a SOQL query containing a subquery is executed through the Global APIs, Salesforce performs an internal query transformation to avoid naming collisions and ensure consistent handling of results.

✅ B. "__ccrz"
This is the correct default suffix.

During transformation, Salesforce appends __ccrz to the subquery name. This:
- Makes the subquery name unique
- Prevents conflicts with standard or custom relationship names
- Allows the Global API layer to safely process nested query results

This behavior is automatic and default, meaning developers do not need to configure it.

Why the other options are incorrect
❌ A. A subscriber-supplied token
The suffix is not configurable. Salesforce controls the transformation internally.
❌ C. The "*" symbol
* is used in queries to mean “all fields”. It is not appended to subquery names.
❌ D. The letter "S"
No such naming convention exists in B2B Commerce query transformations.

Exam tip 🧠
If you see:
- Global API
- Query with subquery
- Transformation behavior
👉 The answer you’re looking for is almost always __ccrz.

Reference
- Salesforce B2B Commerce Global API Developer Guide
- Salesforce Docs: Global API Query Transformations

C.   page (anywhere on it)

Explanation:

Why it's Correct:
Unlike standard Component Events (which bubble up to parents) or Public Properties (which pass data down to children), a Lightning Message Channel operates on a broadcast (pub-sub) model.

Scope: By default, LMS allows communication across the entire DOM of a single Lightning page. This means a component in the header can talk to a component in the footer, even if they are in completely different DOM trees.

Cross-Technology: It isn't limited to just LWCs. It allows Visualforce pages, Aura components, and Lightning Web Components to signal each other simultaneously, as long as they are all on the same page.

Application Scope: If you use the APPLICATION_SCOPE parameter during subscription, the component can even receive messages from different areas of the application, such as a utility bar or different tabs in a console app.

Why Other Answers are Incorrect:
A. only descendants / D. only ancestors: These describe the limitations of Custom Events and @api properties. LMS was specifically created to move beyond these hierarchical constraints.

B. only direct siblings: While LMS is often used for sibling communication, it is much more powerful than that. It does not require components to share a parent; they only need to be active on the same page (or application, if scoped).

Reference:
- Salesforce Developer Guide: Communicate Across the DOM with Lightning Message Service
- Salesforce Blog: Lightning Message Service: Inter-component Communication

A.   Register an Apex class as the integration in the store administration

C.   Create an Apex class implementing the appropriate interface.

D.   Create a named credential for authentication with an external service

Explanation:

When integrating a third‑party service (tax, shipping, or pricing) into a Salesforce B2B Commerce store, developers must follow a structured approach to ensure the service is properly registered, authenticated, and invoked during checkout or calculation flows.

Register an Apex class as the integration (A):
In the B2B Commerce store administration, developers must register the Apex class that implements the integration logic. This ensures the store knows which class to call when tax, shipping, or pricing calculations are required.

Create an Apex class implementing the appropriate interface (C):
Salesforce B2B Commerce provides specific interfaces for tax, shipping, and pricing integrations (e.g., sfdc_checkout.CartPricing, sfdc_checkout.CartTax, sfdc_checkout.CartShipping). Developers must implement the correct interface in their Apex class to handle the external service call and return results in the expected format.

Create a named credential for authentication (D):
Named credentials provide a secure and maintainable way to store authentication details (endpoint URL, credentials, OAuth tokens). This allows the Apex integration class to authenticate with the external service without hardcoding sensitive information.

Why the other options are incorrect:
B. Create a flow to call the external service directly: Not required; integrations are handled via Apex interfaces, not Flows.
E. Create an Apex class with an invocable method: Invocable methods are used for Flows, not for checkout integrations.

✅ In summary:
To implement a third‑party tax, shipping, or pricing service in B2B Commerce, developers must register the Apex integration class, implement the correct interface, and set up a named credential for secure authentication.

A.   ccrz.ccUtil.isNotEmpty(Map) andccrz.ccUtil.isNotEmpty(List

D.   ccrz.ccUtil.isEmpty(Map) and ccrz.ccUtil.isEmpty(List

Explanation:

The ccrz.ccUtil utility class in Salesforce B2B Commerce (classic/Visualforce-based framework) provides helper methods to safely check collections returned from or passed into Global API calls (e.g., ccrz.ccServiceProduct.getProducts, ccrz.ccServiceCart.getCart, etc.). These APIs often use Map<String,Object> for input/output data and List<Object> for collections (products, cart items, etc.).

The two common ways to validate if input or return data is populated (avoiding null pointer exceptions) are:

ccrz.ccUtil.isNotEmpty(Map<String,Object>) and ccrz.ccUtil.isNotEmpty(List<Object>): Returns true if the map/list is not null and contains at least one entry/element. This is ideal for checking if Global API output has meaningful data (e.g., products found, cart not empty) before processing further in subscriber extensions or hooks.

ccrz.ccUtil.isEmpty(Map<String,Object>) and ccrz.ccUtil.isEmpty(List<Object>): The inverse: returns true if the map/list is null or empty. Useful for early exits, error handling, or fallback logic when no data is returned from the API.

These methods are null-safe wrappers around standard Apex checks (size() > 0, isEmpty()), tailored for B2B Commerce's transformed data structures (e.g., ccrz.cc_Output often contains maps/lists).

Why not the others?
Options like isValid or other variants do not exist in ccrz.ccUtil for this purpose.
Standard Apex String.isNotEmpty() or Collection.isEmpty() exist but are not the B2B-specific utilities referenced here.

Reference:
B2B Commerce for Visualforce Developer Guide: ccrz.ccUtil class documentation covers utility methods for collection checks in API contexts.

B.   displayMyData.js-meta.xml

C.   displayMyData.js

E.   displayMyData.html

Explanation

Why they are Correct:
B. displayMyData.js-meta.xml (The Metadata file): This is a mandatory XML file that defines the component's configuration. It specifies where the component can be used (targets like lightning__RecordPage), its API version, and whether it is exposed to tools like the Lightning App Builder. Without this file, the component cannot be deployed to a Salesforce org. C. displayMyData.js (The JavaScript file): This is the brain of the component. It defines the ES6 class that extends LightningElement. For a component that "fetches data," this file would include the @wire service or imperative Apex calls to retrieve records from the Salesforce database.

E. displayMyData.html (The Template file): This provides the structure of your component. It uses standard HTML along with LWC directives (like for:each to loop through data or if:true for conditional rendering) to "display" the data fetched by the JavaScript file.


Why Other Answers are Incorrect:
A. displayMyData.css: While often used to make a component look better, the CSS file is optional. A component will deploy and function perfectly fine using only default SLDS styles or no custom styling at all.

D. displayMyDataController.cls: While you likely need an Apex class to fetch data from the server, that class is a separate entity in the classes folder of your project, not a "file of the LWC" itself. Furthermore, LWC does not follow the "bundle" naming convention of Aura; the Apex class can be named anything and is simply imported into the JS file.

Reference:
- Salesforce Developer Guide: Component File Structure
- Salesforce Trailhead: Create a Lightning Web Component

A.   lightning-record-edit-form

Explanation

The question is asking for the Lightning Web Component that lets a developer view or edit a record while keeping full control over the layout and which fields are shown.

✅ A. lightning-record-edit-form
This is the correct choice.

lightning-record-edit-form allows developers to:
- Specify exactly which fields are displayed
- Control layout and ordering
- Support editing (and viewing) of record data

It’s typically used with:
- <lightning-input-field>
- <lightning-output-field>

This gives the developer fine-grained control, which is exactly what the question is describing.

Why the other options are incorrect
❌ B. lightning-record-imperative
This is not a valid LWC base component.
Record access imperatively is done via getRecord / updateRecord, not a component.

❌ C. lightning-record-view-form
This component is read-only.
You can control which fields appear, but you cannot edit.
The question explicitly includes view or edit.

❌ D. lightning-record-form
This component automatically renders fields.
Layout and field set are largely controlled by page layout.
You do not have full control over the layout or field selection.

Exam tip 🧠
Remember this hierarchy:
- lightning-record-form → fastest, least control
- lightning-record-view-form → read-only, controlled fields
- lightning-record-edit-form → most control, editable

If the question mentions control over layout and fields, always pick
👉 lightning-record-edit-form

Reference
- Salesforce Lightning Web Components Developer Guide
- Trailhead: Use Base Lightning Components for Record Forms

A.   Call this.template.querySelector() and this.template.querySelectorAll()

Explanation:

When using slots in Lightning Web Components (LWCs), content is passed from a parent component into a child component. To access the DOM of what was passed into those slots, developers must query the component’s template.

this.template.querySelector() and this.template.querySelectorAll()
These methods allow you to select elements inside the component’s template, including slotted content.
querySelector() returns the first matching element, while querySelectorAll() returns all matching elements.

Example:
const slotContent = this.template.querySelector('slot');
const assignedNodes = slotContent.assignedNodes();

Here, assignedNodes() gives access to the actual DOM nodes passed into the slot.

Why the other options are incorrect:
B. Call this.querySelector() passing an id: Incorrect. You cannot directly query the DOM outside the component’s template; you must use this.template.

C. Call this.querySelector() and this.querySelectorAll(): Same issue; these methods are not scoped to the component’s template.

D. Call this.template.querySelector() passing an id: While you can pass an id, the key point is that you need both querySelector() and querySelectorAll() for general slot content access.

✅ In summary:
To access DOM content passed into slots, developers use this.template.querySelector() and this.template.querySelectorAll(), then call assignedNodes() on the slot element to retrieve the slotted DOM.

A.   lightning_FlowScreen

Explanation:

To make a custom Lightning Web Component (LWC) usable within a Lightning Flow (which includes the Checkout Flow in B2B Commerce), the component must declare the specific target lightning__FlowScreen in its configuration file (js-meta.xml).

Why it's correct:
The lightning__FlowScreen target is the official, documented metadata target that registers an LWC as a Screen Component compatible with Lightning Flow. This allows Flow Builder to list the component as an option when adding a screen to a flow, and it enables the Flow runtime to pass data to and from the component.

Why the other options are incorrect:
B. lightning__CheckoutFlow: This is a distractor. There is no standard target named lightning__CheckoutFlow. Checkout Flow is a specific implementation of a Lightning Flow, so components use the same target as any other flow screen.

C. Iwe__FlowComponent: This is incorrect naming. It uses an uppercase "I" and lowercase "we" (Iwe), which is not the correct format. Even if it were lwe__FlowComponent, it's not the standard target.

D. lwe__flow: This is incorrect naming and format. The correct prefix for Lightning Web Component targets is lightning__ (with two underscores). lwe__flow is not a valid target.

Key Reference/Concept:
LWC Configuration Targets: The targets in the js-meta.xml file define where the component can be used.
- lightning__AppPage: For Lightning App Builder.
- lightning__RecordPage: For Record Pages.
- lightning__HomePage: For Home Pages.
- lightning__FlowScreen: (Correct Answer) For Lightning Flow screens (including Checkout Flow).

Checkout Flow Integration: To customize the checkout UI with an LWC, you would:
- Create an LWC with the lightning__FlowScreen target.
- Define @api properties in the component's JS to receive data from the flow (e.g., cart ID).
- Reference this LWC as a Screen Component within the Checkout Flow configuration in Business Manager.

Exam Takeaway:
Memorize the key LWC targets. For any component that needs to be used inside a Lightning Flow, the target is lightning__FlowScreen. Note the correct spelling, prefix (lightning__

C.   A class will need to implement the sfdc_checkout.CartShippingCharges interface

D.   The implementing class may need to contain logical branching

Explanation

To implement a specific business rule for shipping costs (like switching between freight and standard rates) in a B2B Commerce checkout, the developer must hook into the standard shipping integration point:

C. Implement the interface: The sfdc_checkout.CartShippingCharges interface is the mandatory Apex contract for custom shipping integrations. It requires the developer to define the startCartProcessAsync method, which is where the custom logic for determining available shipping options resides.

D. Logical branching: This is the core of the business requirement. The developer must write Apex logic (e.g., if (cartTotal > X) { ... } else { ... }) to check the cart amount. Based on that branch, the code will either return a fixed Freight cost or return the Standard shipping rates.

Why other options are incorrect
❌ A. sfdc_commerce.CartShippingCharges: This is an incorrect namespace. As with most checkout integrations (Tax, Price, Inventory), the shipping interface resides specifically within the sfdc_checkout namespace.

❌ B. The implementing class cannot call out to another service: This is false. One of the primary reasons to implement this interface is to perform a REST or SOAP callout to an external shipping provider (like FedEx or UPS) to retrieve real-time rates.

Reference:
Integrate an External Shipping Service | Salesforce B2B Commerce Developer Guide