B2B-Commerce-Developer Practice Test Questions (2026)

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.

Explanation:

In the context of the Salesforce B2B Commerce Developer exam, this approach leverages built-in platform integration capabilities without requiring external middleware or specialized third-party tools.

Waystation Approach: Using an SFTP server allows the external system to "drop" its data files independently. This acts as a decoupled buffer between the two systems.

Built-in Integration: B2B Commerce Classic (CloudCraze) features an Integration Job framework. You can configure a scheduled job on-platform (within the Salesforce org) that is programmed to poll the SFTP server, fetch the data files, and process them into the B2B Commerce objects.

No Third-Party Tools: This process relies on standard protocols (SFTP) and native Salesforce/B2B Commerce scheduling and Apex processing, satisfying the "no additional third-party tools" constraint.

Why the others are incorrect:

A: Installing the CLI and creating scripts counts as using an additional set of tools (the Salesforce CLI) that must be maintained and secured on an external machine.

C: WebDAV is typically used for B2C Commerce (Demandware) file transfers for static assets or code, and is not the standard "waystation" pattern taught for B2B Commerce data integration jobs.

D: This describes a complex manual reconciliation process that is not a standard "scheduled job" pattern for moving data into an org and involves unnecessary "pushing" to a specific import directory that does not exist in this native way on the platform.

Reference
B2B Commerce Developer Guide: Review the sections on Integration Job Definitions and the Windows Integration Service (WIS) (for older implementations) or native Apex-based SFTP processing.
PrepBolt B2B Commerce Study Material: Specifically identifies Option B as the correct architectural pattern for this exam scenario.

Explanation:

Core Concept: This question tests the process for customizing the data layer in B2B Commerce (Aura/LWR) to expose new fields on storefront pages. It distinguishes between the "Service Class" and the "Logic Class" in the B2B Commerce data architecture.

Why This Answer is Correct:

In the B2B Commerce data framework:

- Service Classes (e.g., cc_apex_ctrl_ProductDetails) are responsible for building the data model that is sent to the storefront. They query the necessary objects and fields and structure the response.
- To expose a new custom field on a page (e.g., Product Details), a developer must override the existing Service Class for that page, extending it to include the new field in its query and data structure.
- After creating the new Service Class, it must be registered in CC Admin > Service Management for the specific storefront. This tells the framework to use your custom class instead of the standard one, making the field available to the page's components.

Why the Other Answers are Incorrect:

B. Override the Logic Class: Logic Classes (e.g., cc_logic_ProductDetails) are responsible for business logic (calculations, transformations, validations) on the data after it is retrieved by the Service Class. They do not control which fields are initially queried from the database. Overriding a Logic Class would not make a new field available; it would only allow you to perform operations on data that is already being fetched.

C. Create a new Service Class: While technically you could create a brand new Service Class from scratch, the standard, supported practice is to override the existing OOTB class. This ensures you inherit and maintain all the existing functionality and only add your customizations. The OOTB framework expects specific class names and structures; creating a completely new one would likely break the page unless you also overrode numerous other dependencies.

D. Create a new Logic Class: As explained in B, Logic Classes handle processing, not data retrieval. Creating a new one would not make the field available from the database.

Key References / Considerations:

- Data Flow: The standard flow is: Page Request -> Service Class (queries data) -> Logic Class (applies business rules) -> UI Component.
- CC Admin Registration: The registration step in Service Management is critical. Without it, your custom class will not be invoked.

Example: To add a custom field My_Custom_Field__c to the Product Details page, you would:
- Create a class myCustomProductDetails that extends cc_apex_ctrl_ProductDetails.
- Override the method that builds the query to include My_Custom_Field__c.
- In CC Admin, go to Service Management, find the Product Details service, and set your new class as the Service Implementation.

This is a fundamental pattern for customizing the data exposed in B2B Commerce and is a heavily tested concept on the exam.

Explanation

In Salesforce debug logs, a Code Unit represents a discrete unit of work executed within a transaction. When you analyze a debug log (especially at the INFO or FINE levels), the system generates CODE_UNIT_STARTED and CODE_UNIT_FINISHED events to track these specific executions.

A. Validation rule: These are considered discrete units of work because they are evaluated as part of the "Save" order of execution and are logged individually to show whether the record passed or failed the criteria.

B. Apex class: Specifically, the entry points like a Trigger, a Web Service method, or an @AuraEnabled method are tracked as code units.

E. Workflow invocations: Workflow rules and their associated actions (like Field Updates) are discrete events in the order of execution and are explicitly logged as code units.

Why the others are incorrect:

C. Web service invocation: While a web service request starts a transaction, the "invocation" itself is usually a CALLOUT or a generic SYSTEM_METHOD. The actual unit of work inside the Salesforce org would be the Apex method handling the service, not the invocation event itself.

D. Lightning component load: The loading of a component happens primarily on the client side (browser). While it might trigger server-side Apex (which would be a code unit), the act of "loading" the UI framework isn't a discrete code unit within the Salesforce server-side transaction log.

Reference
Salesforce Developer Guide: Debug Log Levels and Events.
Order of Execution: The official documentation on the Triggers and Order of Execution lists these items as part of the transactional units that Salesforce monitors.

Explanation:

Core Concept: This question tests knowledge of the specific B2B Commerce JavaScript controller method used to trigger the display of user-facing messages (info, warning, error) within the Visualforce-based (Aura) storefront.

Why This Answer is Correct:

Within the B2B Commerce Visualforce architecture, the displayPageMessage() function is the standard, framework-provided method invoked to render a message to the user. It is part of the ccrz.js library. When an action (like adding to cart) completes, the Apex controller returns a ccrz.cc_RemoteActionResult object that contains message data. The framework's JavaScript then calls displayPageMessage() to process this data and visually display the message in the designated area on the page.

Why the Other Answers are Incorrect:

A. showMessage: This is not a standard B2B Commerce framework method. It might be a custom function a developer could write, but it is not the prescribed event for the OOTB message display system.

C. displayMessage: This is close but incorrect. The exact method name is displayPageMessage.

D. pageMessage: This is not a valid method name in the B2B Commerce JavaScript API.

Key References / Considerations:

- Framework Integration: This method is tightly integrated with the ccrz.cc_RemoteActionResult structure. The result.messages collection in the action result is what displayPageMessage() processes.
- Visualforce Context: This answer applies specifically to the legacy Aura/Visualforce storefront. In the newer LWR (Lightning Web Runtime) storefront, messages are typically handled differently, often using Lightning Web Component patterns (e.g., the lightning/platformShowToastEvent module or custom eventing).
- Customization: While the framework calls this method automatically, developers can also call it manually in custom JavaScript to display messages, ensuring a consistent UI.
- Exam Focus: Knowing the exact naming conventions of key framework methods is a common exam topic.

This is a detail-oriented question that tests familiarity with the specific APIs of the legacy B2B Commerce platform.