Free B2B-Commerce-Developer Practice Test Questions (2026)

Explanation:

In modern Salesforce B2B Commerce (especially LWR/Lightning Experience storefronts using Lightning Web Components), the checkout process is highly customizable through custom LWCs placed on the Checkout page or within custom checkout flows. The standard payment component handles core payment processing (like credit cards via Salesforce Payments or integrated gateways), but for non-standard or conditional payment types like Purchase Order (PO) and a custom "Contract Now & Pay Later" (likely a deferred payment or invoicing option tied to contracts), you need more control.

Purchase Order is natively supported in B2B Commerce (often via the dual payment component or PO-specific handling), but "Contract Now & Pay Later" is not a standard out-of-the-box payment type—it's custom logic. Conditional visibility based on a custom checkbox field on the Account (e.g., Allow_Deferred_Payment__c) requires querying the effective Account record (via the cart's associated buyer/account) and dynamically showing or hiding options.

Why B is the Best Approach:
A custom LWC for the payment/checkout section can:
Display all three options (Credit Card via standard integration, PO as a radio or checkbox option, and custom "Contract Now & Pay Later" as another selectable option).
Use @wire with Lightning Data Service (or imperative Apex if needed) to fetch the Account record and check the custom checkbox.
Conditionally render the PO and "Contract Now & Pay Later" options only if the checkbox is true.
Handle selection logic, validation, and pass the chosen payment type to the checkout flow (for example, via custom properties or events to update the cart or order).

This approach is declarative where possible but allows full programmatic control for complex conditions tied to Account data, which is not natively supported in standard payment components or simple screen flow visibility rules for payment options.

Why the Other Options Are Incorrect:
A — Using pub-sub with the standard payment component is possible for some interactions, but the standard payment component does not natively expose events for conditionally adding or showing non-standard payment types like "Contract Now & Pay Later." It is not the cleanest or recommended way for full control over the UI and logic.

C — Screen flows in B2B Commerce checkout support expression-based visibility rules, but the standard payment component does not allow adding arbitrary new payment methods (like "Contract Now & Pay Later") through configuration alone. Visibility rules work for hiding or showing entire components or fields, but not for dynamically filtering options inside the built-in payment UI. PO is supported, but custom types require extension.

D — Adding a new payment gateway (via reference implementations like Adyen, Stripe, etc.) is intended for processor integrations (such as credit card variants), not for non-gateway methods like PO or custom deferred payments. PO does not use a gateway, and "Contract Now & Pay Later" is not a gateway-based method.

References:
Salesforce Help: "Customize the Payment Section of Checkout in a Commerce Store" — Recommends custom LWCs for advanced payment UI and processing beyond standard Salesforce Payments.
B2B Commerce Developer Guide: Custom checkout component examples (such as a Terms and Conditions LWC) demonstrate how to build and extend checkout sections with conditional logic.

Explanation:

In Salesforce B2B Commerce, when customizing the Add to Cart experience, the key requirement is that the mini cart module reflects the updated cart state after items are added.

The global cartChange event is the standard event fired whenever the cart’s state changes.

By triggering this event after the custom Add to Cart action, the mini cart (and any other components listening for cart updates) will automatically refresh and display the new cart state.

This ensures consistency across the storefront without requiring additional custom events or remote actions.

Why the Other Options Are Incorrect
A. Leverage the Add to Cart Global API which adds items to the cart and also refreshes the page with the new data.
→ Incorrect. The API adds items but does not automatically refresh the mini cart; the event must be triggered.

B. Trigger the global cartChange event and then trigger changeMiniCart event after the Add to Cart Action.
→ Incorrect. There is no changeMiniCart event; only cartChange is required.

C. Write a custom Remote Action to refresh the Mini Cart and refresh the Cart Line item count.
→ Incorrect. This is unnecessary custom work; the cartChange event already handles this.

References
Salesforce B2B Commerce Developer Guide: Cart Events and Mini Cart Updates
Salesforce Help: Using the cartChange Event in Storefront Customizations

Explanation:

In Salesforce (including B2B Commerce development), when a developer suspects a defect in a small, isolated block of Apex code (e.g., 30 lines), the fastest and most effective way to add debug statements (e.g., System.debug('Variable value: ' + var);), run the code in isolation, and observe immediate results is to use the Execute Anonymous window.

This tool is available in:
* Developer Console (Debug → Open Execute Anonymous Window)
* VS Code with Salesforce Extensions (via "Execute Anonymous Apex" command or .apex files)
* Workbench or other tools supporting anonymous Apex execution

Key advantages for this scenario:
* Paste or write the 30-line code block directly (with added System.debug() statements)
* Execute it immediately in the current org context (user permissions, data visibility)
* View real-time output in the Execution Log (filter by DEBUG level to see System.debug messages instantly)
* No need to deploy classes, trigger triggers, or simulate full user flows (e.g., no storefront interaction required)
* Ideal for quick isolation testing, variable inspection, exception catching, or logic validation without affecting production flows

Why the other options are incorrect:

A. Click the Check Out button in the storefront — This triggers the full checkout process (involving multiple services, integrations, flows), not isolated execution. It doesn't allow adding debug statements or running just the 30 lines independently.

C. Activate Chrome dev tools and click the Check Out button in the Storefront — Chrome DevTools is for client-side JavaScript/HTML/CSS debugging (e.g., network requests, console logs from Visualforce or LWC). It cannot execute, debug, or observe server-side Apex code in isolation.

D. Use the Execute Immediate window — There is no standard "Execute Immediate" window in Salesforce. This is likely a distractor term (possibly confusing with Oracle PL/SQL "EXECUTE IMMEDIATE" or a typo/misremembered name). The correct Salesforce feature is "Execute Anonymous."

References
Salesforce Developer Console Help: "Executing Anonymous Apex Code" — Describes using the Execute Anonymous window for ad-hoc code execution with debug output
Trailhead: Apex Basics modules — Teaches Execute Anonymous for quick testing/debugging of code snippets

Explanation:

In Salesforce B2B Commerce for Visualforce (CloudCraze), ccLog is a specialized logging utility designed to bridge the gap between server-side Apex execution and client-side visibility.

A. Tagging Logic
The ccLog methods (e.g., ccrz.ccLog.log(LoggingLevel.INFO, 'Subject', data)) natively accept a "Subject" parameter. This automatically categorizes the log entry in the output, whereas System.debug requires you to manually concatenate strings (e.g., System.debug('Subject: ' + data)) to make logs searchable.

C. No Trace Flags
Standard Salesforce debugging requires setting up a Trace Flag in Setup > Debug Logs for a specific user. ccLog bypasses this requirement by outputting data directly to the browser console when a valid token is used, saving the developer from repetitive setup in the Salesforce UI.

E. Guest User Debugging
Debugging the Site Guest User (unauthenticated shoppers) with System.debug is notoriously difficult, often requiring "Debug Mode" for the site or complex cookie mapping. ccLog handles this gracefully by allowing the developer to view guest user execution logic simply by using the logging token in the URL.

Why Other Options are Incorrect

B. Debug JavaScript syntax errors
ccLog is an Apex class. While it outputs to the JavaScript console, it cannot detect syntax errors within your .js files; those must be caught by the browser's native interpreter or LWC compiler.

D. Append #ccLog= to the URL
This is a trick question regarding syntax. To activate the logs, you must append the logging token as a URL parameter using &ccLog=token (or ?ccLog=token), not a URL fragment or hash (#).

Pro Tip for the Exam:
Remember that ccLog is only available if you have first generated a Logging Token in CC Admin > Global Settings.

Explanation:

If Northern Trail Outfitters (NTO) needs to access historical data stored in another system, display it inside Salesforce, keep it read-only, avoid importing the data, and avoid consuming Salesforce storage, the correct solution is External Objects.

External Objects allow Salesforce to access data stored outside the org in real time using Salesforce Connect.

They:
- Use OData or custom adapters
- Do not store data in Salesforce
- Do not consume Salesforce storage
- Support read-only access (depending on configuration)
- Can be displayed in the UI like standard objects
- Can be related via Indirect Lookup Relationships

This is the ideal architecture for large volumes of historical data that should remain in an external system.

Why the Other Options Are Incorrect

A. Big Objects
Big Objects store massive amounts of data inside Salesforce. They are designed for large data volumes but still reside in the org and are not meant for real-time external referencing.

B. Lightning Out
Lightning Out allows embedding Lightning components in external systems. It does not enable referencing external data inside Salesforce.

D. External SOQL queries in Apex code
There is no such feature as “External SOQL queries” in Apex for external systems without integration logic.

To access external data via Apex, you would need:
- Callouts
- Middleware
- Custom integration

That does not meet the requirement of a declarative, read-only, no-storage solution.

Exam Tip (AP-202 & Salesforce Developer)
If the question includes:
- “Do not store data”
- “Avoid storage costs”
- “Access external data”
- “Large historical data”
- “Read-only reference”

The answer is almost always External Objects (Salesforce Connect).

Explanation:

When adding custom content to the HTML tag in Salesforce B2B Commerce, developers can either use CloudCraze Page Include sections (HTMLHead Include Begin/End) or the ccrz.cc_hk_UserInterface Apex hook extension.

It is preferred to use the UserInterface hook extension because:

Apex include limitations (A)
The apex:include directive is wrapped in [apex:page](apex:page) tags.
This makes it unsuitable for injecting content directly into the section.

HTML restrictions (D)
Standard HTML does not allow [apex:include](apex:include) tags inside the element.
Using Page Include sections can cause invalid markup or runtime issues.

By contrast, the ccrz.cc_hk_UserInterface hook provides a clean, supported way to inject scripts, styles, or metadata into the without breaking HTML standards.

❌ Why the Other Options Are Incorrect
B and C are duplicates or incomplete variations of the same reasoning. The correct and complete explanations are captured in A and D.

📚 References
Salesforce B2B Commerce Developer Guide: Hooks and UserInterface Extension
CloudCraze Technical Documentation: HTMLHead Includes vs. UserInterface Hook

Explanation:

Subscriber Pages in Salesforce B2B Commerce (CloudCraze) are designed to allow developers and administrators to extend the storefront safely without modifying managed package pages.

They provide a structured way to add custom content while still leveraging the existing storefront framework.

✅ A. Can include standard Commerce components (Correct)
Subscriber pages support adding existing Commerce components such as:
Featured Products
Category Tree
Mini Cart
Product listings
This allows reuse of built-in functionality.

✅ C. Enable quick creation of custom storefront pages (Correct)
Subscriber pages are specifically intended to:
Create new storefront experiences
Add custom business functionality
Extend navigation without overriding core pages

✅ E. Standard components automatically included (Correct)
Subscriber pages inherit the storefront layout framework, including:
Header
Navigation/menu
Containers/layout structure
Styling and theme
Developers only add the custom content section.

❌ Why the Other Options Are Incorrect
❌ B. All UI components must be created manually
Incorrect — subscriber pages reuse many out-of-the-box Commerce components.

❌ D. Out of the box they are completely blank HTML pages
They are not blank; they inherit the Commerce page structure and layout.

Explanation:

Salesforce B2B Commerce (CloudCraze) storefronts are built on a managed package that leverages a mix of front-end frameworks for templating, styling, and client-side logic. Knowing which frameworks are in play is important for developers extending or customizing storefront experiences since it dictates which conventions and tools are available out of the box.

Correct Option

✅ B. Bootstrap, Backbone.js, and Handlebars.js
CloudCraze relies on Bootstrap for responsive CSS design and layout, Backbone.js for structuring JavaScript code with models and views, and Handlebars.js for dynamic templating. This trio provides a clean separation of responsibilities: styling, client-side logic, and templating. Developers extending CloudCraze themes or storefronts are expected to understand these frameworks to build consistent and maintainable features.

Incorrect Options

❌ A. AngularJS, Backbone.js, and Handlebars.js
AngularJS is not part of the CloudCraze package. While it is a popular JavaScript framework, CloudCraze instead uses Bootstrap for styling and responsiveness. Including AngularJS here is a distractor because it overlaps in purpose with Backbone.js.

❌ C. Bootstrap, AngularJS, and Backbone.js
This mix leaves out Handlebars.js, which is central to the templating system CloudCraze uses. AngularJS again doesn’t belong in the architecture, and without Handlebars, the option misses the framework that handles the dynamic rendering of HTML.

❌ D. AngularJS, React.js, and Handlebars.js
Neither AngularJS nor React.js is included in the managed package. CloudCraze predates React adoption and never relied on it. This option might trick someone familiar with modern frontend stacks, but it doesn’t match the CloudCraze reality.

Reference:
Salesforce Help – B2B Commerce Developer Guide

Explanation:

When troubleshooting checkout flow errors in Salesforce B2B Commerce, developers should focus on two key activities:

Compare flow versions (B):
Reviewing previous versions of the flow against the current one helps identify what changes may have introduced the bug. This is a standard debugging practice to isolate regressions.

Debug with inputs (C):
Using the Flow Debug tool allows the developer to simulate the flow with the same inputs that triggered the error. This provides visibility into where the flow fails and helps confirm the root cause.

Why the Other Options Are Incorrect

A. Use the Org Browser tool in the IDE to download the flow XML and run a diff report:
While technically possible, this is not the recommended or standard approach for debugging flows. Salesforce provides version comparison and debug tools directly.

D. Attach to Live Session:
Not a supported method for debugging flows. Flows are debugged using the built-in Debug option, not by attaching to live sessions.

Reference:
Salesforce Flow Debugging Guide: “Use the Debug option in Flow Builder to test flows with specific inputs. Compare flow versions to identify changes that may have introduced errors.”

Explanation:

These statements accurately describe the event handling architecture in the Salesforce B2B Commerce managed package:

C:
Salesforce B2B Commerce relies on a central event channel called CCRZ.pubSub for communication across various Backbone Views and Models. This pub/sub (publish/subscribe) pattern enables decoupled communication between components.

D:
defines the standard event handling functions: trigger (to publish events), on (to subscribe to events), and once (to subscribe to an event for a single occurrence). These are the core methods for event-driven communication.

E:
extends the Backbone.Events JavaScript object, which provides the event handling capabilities. This inheritance gives CCRZ.pubSub all the event methods from Backbone.Events.

Why the Other Options Are Incorrect:

A:
While JavaScript click listeners may exist in the UI, the B2B Commerce architecture primarily relies on the pubSub event channel for component communication, not a series of direct click listener events.

B:
Writing directly to custom Backbone Views and Models does not automatically integrate that data into the Salesforce B2B Commerce Backbone Views and Models. Custom data must be explicitly synchronized or communicated through proper channels like pubSub events.

Reference:
Salesforce B2B Commerce Developer Guide: Event Handling with CCRZ.pubSub