B2B-Commerce-Developer Practice Test Questions (2026)

Explanation:

When troubleshooting why a field is not displaying on the Product Detail Page in Salesforce B2B Commerce, the key is to inspect the data model that feeds the page rather than the rendered UI.

C. CCRZ.productDetailModel
Typing CCRZ.productDetailModel in the browser Developer Tools Console allows a developer to:

View all product fields and values available to the Product Detail Page
Confirm whether a field is being returned from the backend
Confirm whether a field is exposed to the storefront
Distinguish between data availability issues where the field is not in the model and rendering issues where the field exists but is not shown in the UI

This is the correct object to inspect when debugging missing fields on the Product Detail Page and is a commonly tested exam detail.

Why the other options are incorrect

A. CCRZ.productSearchView
This is used for search and product listing pages and is not related to the Product Detail Page.
B. CCRZ.cartView
This contains cart-related data and has nothing to do with product detail rendering.
D. CCRZ.productDetailView
This represents the view layer rather than the underlying data model and is not where you verify whether a field is actually available.

Exam tip 🧠
When debugging storefront issues:
Model equals the data that is available
View equals what is rendered

If a field is missing on the Product Detail Page, always check productDetailModel first.

Reference
Salesforce B2B Commerce Developer Guide
Trailhead: Debug B2B Commerce Storefronts Using Browser Tools

Explanation:

In Lightning Web Components, the <slot> element is used to pass HTML content from a parent component into a child component. This concept is known as content projection.

The parent places markup inside the child component’s tags, and the child defines a <slot> where that markup will be rendered.

Why the other options are incorrect

A. <template>
Used to define conditional rendering or iteration in Lightning Web Components, not for passing content between components.

C. <lightning-input>
A base Lightning component used for input fields and is unrelated to content projection.

D. <shadow>
Refers to the Shadow DOM concept, but it is not an element that is directly used in Lightning Web Components.

Reference
Salesforce Developer Guide: Slots in Lightning Web Components

Explanation:

To integrate an external, sophisticated pricing engine into the B2B Commerce checkout flow, the developer must both call the external service and implement the specific Salesforce checkout integration interface that handles price calculations.

A. Make a call to the service
This is the fundamental action. After establishing security, typically via Named Credentials or Auth Providers, the developer must write Apex code that performs the HTTP callout using HttpRequest and HttpResponse to the external pricing service API endpoint, sends the required cart and line item data, and processes the returned pricing information.

D. Implement the sfdc_checkout.CartPriceCalculations
This is the mandatory Salesforce-side integration point. sfdc_checkout.CartPriceCalculations is a global Apex interface provided by Salesforce for custom pricing integrations during checkout. The developer must create an Apex class that implements this interface. The class contains the startCartProcessAsync and or startCartProcessSync methods, where the logic to call the external service and return updated pricing to the checkout flow is implemented.

Why the other options are incorrect

B. Use External Objects
External Objects are designed to map and query external data sources as if they were Salesforce objects. They are not intended for calling transactional pricing services that perform real-time calculations during checkout. Pricing engines are typically accessed via APIs, not queried like database tables.

C. Implement the sfdc_checkout.PriceCalculations
This is an incorrect interface name. The correct and documented interface for custom cart pricing calculations is sfdc_checkout.CartPriceCalculations. Knowing the exact interface name is a common exam requirement.

Key reference and concept

Checkout flow integration
The B2B Commerce checkout is implemented as a sequence of checkout flow steps. The Calculate Cart Totals step is designed to invoke any Apex class that implements the sfdc_checkout.CartPriceCalculations interface.

Integration architecture
Define integration by creating an Apex class that implements sfdc_checkout.CartPriceCalculations
Call the external service from within the interface method using a secure HTTP callout
Process the service response and update the CartSummary object passed into the method
Configure the checkout flow to reference this Apex class in Business Manager

Security
The scenario assumes security and trust are already established, meaning Named Credentials or remote site settings are in place. The developer’s responsibility is implementing the integration logic.

Exam takeaway
For any custom pricing, tax, or shipping integration in the B2B Commerce checkout flow, you must implement the correct Salesforce-provided Apex interface such as CartPriceCalculations, CartTaxCalculations, or CartShippingCalculations and pair it with an external service callout. Knowing the exact interface names is essential for the exam.

Explanation:

Why it is correct
A Subscriber Page, often referred to as a CC Page, is the standard mechanism for adding a custom standalone page to a B2B Commerce storefront while inheriting the global storefront theme.

Consistency
By defining a Subscriber Page, the B2B Commerce engine automatically wraps the custom content with the standard storefront header and footer, ensuring a consistent look and feel.

Routing
A Subscriber Page allows you to define a unique URL key, for example ccrz__CCPage?pagekey=ContactUs, making the page accessible directly through the storefront routing system.

Implementation
Typically, a Visualforce page is created for the Contact Us lead form and then linked to a CC Page record in the CC Admin settings. This approach ensures that all required storefront CSS and JavaScript libraries are correctly loaded.

Why other answers are incorrect

A. Page Include
Page Includes are used to inject custom content into existing storefront pages, such as adding a section to the Home Page. They are partial fragments and do not represent full pages with their own URL keys.

C. Subscriber Template
A Subscriber Template defines the layout structure of pages, such as changing from a two-column layout to a three-column layout. It does not create new pages; it only controls visual structure.

D. Body Include Begin
This configuration option is used to inject code immediately after the body tag across the storefront, commonly for analytics or custom scripts. It is not intended for creating functional pages like a Contact Us form.

Reference
Salesforce B2B Commerce Developer Guide: Create a Subscriber Page

Explanation:

When setting up a new B2B Store in Salesforce, the Commerce Setup Wizard includes an option to Add Sample Data. This is the fastest route because it automatically populates the store with:

- A sample Product Catalog and Categories
- Price Books and Price Book Entries
- Buyer Groups and Entitlement Policies
- CMS Workspace content for images

This allows a developer to immediately begin testing and developing Checkout Flows or custom components without manually building the complex relational data model required for commerce.

Why other options are slower

A. Import a previously exported store archive
While effective for cloning, this requires having an existing valid export and managing dependencies like organization IDs and network settings.

B. Use sfdx setup scripts
While powerful for CI/CD, writing or customizing these scripts takes significantly more initial time than clicking a checkbox in the UI.

D. Import the data with Data Loader
This is the most time-consuming method, as it requires importing multiple objects (Products, Price Books, Catalogs, Categories, etc.) in a specific sequential order to maintain record relationships.

References
Create a B2B Store | Salesforce Help
Sample Data for Commerce | Salesforce Developer Guide

Explanation:

Lightning Data Service (LDS) is a declarative, client-side data access layer in Salesforce (used in both Aura and Lightning Web Components) that simplifies interacting with Salesforce records while optimizing performance and consistency. It leverages the User Interface API under the hood and provides managed caching, sharing, and synchronization.

Combines and de-duplicates server calls (C is correct)
LDS optimizes network traffic by bulkifying (batching) multiple requests for the same record or related data and de-duplicating redundant calls. If several components request the same record (or overlapping fields), LDS consolidates them into a single server request instead of firing separate ones. This reduces server round-trips, lowers latency, and improves overall app performance—especially on pages with multiple components displaying shared data.

Loads record data progressively (D is correct)
LDS supports progressive loading: it returns data from the client-side cache immediately (if available) for a fast initial render, then asynchronously fetches any missing or updated fields from the server and merges them into the local cache. This provides a snappy UI experience—users see partial data quickly while the rest loads transparently in the background. It only loads requested fields initially and adds more as needed, for example, when another component wires in additional fields.

Why not the others?

A. Communicates with other components
LDS enables data consistency across components (e.g., updating one component refreshes others via cache invalidation), but it does not directly handle inter-component communication. That is managed via @api, events, or pub/sub patterns.

B. Converts between different data formats
LDS works with Salesforce sObject records in their native format and does not perform data format conversions, such as JSON ↔ XML or custom transformations. Those tasks are handled in custom code or Apex.

Reference
Official Salesforce Developer Documentation: Lightning Data Service — Explicitly states: "Lightning Data Service does a lot of work to make code perform well. Loads record data progressively. ... Optimizes server calls by bulkifying and deduping requests." Also covers client caching, sharing across components, and progressive field loading.
Additional sources: Trailhead, Salesforce Ben, and Apex Hours articles highlight these performance advantages (caching, deduping requests, progressive loading) as core benefits over manual Apex/@wire calls.

These features make LDS ideal for B2B Commerce scenarios, such as product detail pages, carts, or checkout components, where multiple Lightning Web Components need consistent, efficient access to shared records like products or orders without redundant Apex or server hits.

Explanation:

In the legacy Visualforce-based B2B Commerce ("CCRZ") architecture, the JavaScript framework uses a specific event naming pattern to notify other parts of the application when key lifecycle stages of a page view are complete.

The view:*:rendered event is the standard, documented event that is fired after a Commerce page view has been fully rendered in the browser. The asterisk (*) is a wildcard representing the specific view name (e.g., view:cart:rendered, view:productDetail:rendered).

Why it's correct
This event allows developers to execute custom JavaScript code that needs to run after the page's HTML is fully in the DOM and the initial data binding is complete. It is a common hook for integrating third-party scripts, manipulating the DOM, or initializing custom UI components.

Why the other options are incorrect

A. view:*:load
This is not the standard event name. The correct event for when the view's data model has been loaded from the server (but before rendering) is typically view:*:loaded or is handled by other callbacks.

B. view:*:refresh
This event is typically fired when a view's data is explicitly refreshed or reloaded (e.g., after updating the cart), not after the initial render cycle.

C. view:*:onload
This is a distractor. While onload is a common native JavaScript event for the window or an image, it is not the specific event name used by the CCRZ framework's view lifecycle. The framework uses its own event system with the view:*:rendered convention.

Key Reference/Concept
CCRZ JavaScript Event System: The framework has a publish/subscribe model. Key events follow the pattern view:[viewName]:[event].

Common View Lifecycle Events:
- view:*:loading: View begins loading.
- view:*:loaded: View data is loaded.
- view:*:rendered: (Correct Answer) View is fully rendered in the DOM.
- view:*:refresh: View data is refreshed.

Use Case
This is critical knowledge for customizing the storefront's frontend behavior in the Visualforce model. For example, to run a script on the product detail page after it renders, you would listen for view:productDetail:rendered.

Exam Takeaway
Memorize the key CCRZ view events, especially rendered as the post-render hook. The AP-202 exam tests knowledge of this legacy architecture's specific patterns. In the newer LWC-based architecture, you would use LWC lifecycle hooks like renderedCallback() instead.

Explanation:

In Salesforce B2B Commerce, API sizing blocks are a mechanism used to handle multiple API sizing requests efficiently. They allow developers to manage how sizing information (such as product dimensions, shipping calculations, or other entity-specific sizing data) is processed and reused across different requests. Understanding how these blocks support multiple requests is important for optimizing performance and ensuring consistency in commerce applications.

Different entities specified in the method invocation (A)
When a developer invokes the sizing method with different entities (for example, different product SKUs or different cart items), the sizing block can handle these requests separately. This ensures that each entity’s sizing data is processed without overwriting or conflicting with another entity’s data.

The sizing block is not removed (B)
By default, sizing blocks can persist across multiple requests if they are not explicitly removed. This persistence allows subsequent API calls to reuse the same sizing block, reducing redundant recalculations and improving efficiency. Developers can leverage this behavior to streamline workflows where multiple sizing requests are needed in sequence.

SZ_ASSC is used (C)
The SZ_ASSC (Sizing Association) mechanism is critical for linking sizing blocks to specific entities or contexts. When SZ_ASSC is used, the sizing block can be associated with multiple requests, ensuring that the correct sizing data is applied consistently across different API calls. This association is what enables the block to support multiple requests without confusion or duplication.

Incorrect options:

D. The sizing block is removed after the first handler
This would prevent reuse, so it does not support multiple requests.

E. SZ_ASSC is not used
Without SZ_ASSC, the block cannot properly associate with multiple requests, making it ineffective for this purpose.

Reference
Salesforce B2B Commerce Developer Guide: API Sizing and SZ_ASSC usage

Explanation:

To accept credit card payments in a Salesforce B2B Commerce store using a client’s chosen (external) payment provider, Salesforce requires a combination of secure authentication, Apex extensibility, and provider registration.

These three actions together form the complete and supported payment integration pattern.

A. Create a named credential for authentication with the payment provider
This is required.
Payment providers are external services.
Salesforce best practice (and expectation on the exam) is to use Named Credentials to:
- Store endpoints
- Handle authentication securely (OAuth, API keys, etc.)
This avoids hardcoding credentials in Apex and simplifies callouts.

C. Create an Apex class that implements the sfdc_checkout.PaymentGatewayAdapter
This is required.
sfdc_checkout.PaymentGatewayAdapter is the official B2B Commerce interface.
Your Apex class must implement this interface to:
- Authorize payments
- Capture payments
- Handle payment responses from the provider
Salesforce invokes this class during checkout payment processing.
This is the core development step.

D. Create a PaymentProviderGateway record for the custom payment provider class
This is required.
The PaymentProviderGateway record:
- Registers your Apex adapter class with B2B Commerce
- Makes the payment provider selectable and usable in the store
Without this record, Salesforce cannot connect checkout flows to your custom gateway logic.

Why the other options are incorrect

B. Create a RegisteredExternalService record for the custom payment provider class
RegisteredExternalService is used for external service integrations.
It is not part of the B2B Commerce payment provider setup.
Payments use PaymentProviderGateway, not RegisteredExternalService.

E. Create an Apex class that implements the commerce payments. Payment Gateway Adapter
This interface does not exist.
The correct and supported interface is: sfdc_checkout.PaymentGatewayAdapter.
This option is a classic exam distractor.

Exam tip 🧠
If the question says:
Credit card payments
External payment provider
B2B Commerce checkout
Look for this trio:
- Named Credential
- sfdc_checkout.PaymentGatewayAdapter
- PaymentProviderGateway record

Reference
Salesforce B2B Commerce Checkout Developer Guide
Salesforce Docs: Integrate Payment Gateways in B2B Commerce
Trailhead: Customize Payments in Salesforce B2B Commerce

Explanation:

Why they are Correct:
A. An Aura component can contain another Aura component
This has been the standard behavior of the Aura framework since its inception. Aura was designed for nested composition within its own framework.

B. An Aura component can contain a Lightning Web Component
To allow developers to migrate to the newer LWC framework gradually, Salesforce designed Aura to act as a container for LWCs. This allows you to use a modern LWC inside an existing legacy Aura page or component.

D. A Lightning Web Component cannot contain an Aura component
This is a fundamental technical constraint. LWC is built on modern web standards and sits "lower" in the stack than Aura. Because Aura is a heavier, legacy abstraction, an LWC cannot act as a parent to an Aura component. Composition only works one way: Newer (LWC) inside Older (Aura).

Why Other Answers are Incorrect:
C. A Lightning Web Component can contain an Aura component
As explained above, this is technically impossible due to the architecture of the Lightning framework. If you try to nest an Aura component inside an LWC, the component will fail to render or save.

Reference
Salesforce Developer Guide: LWC and Aura Interoperability
Salesforce Trailhead: Lightning Web Components for Aura Developers