B2B-Commerce-Developer Practice Test Questions (2026)

Explanation:

This question focuses on logging best practices used internally by the Salesforce B2B Commerce (CCRZ) core product. Salesforce is very intentional about logging because of performance, security, and log noise concerns.

✅ B. The close method of ccrz.ccLog must be called at the end of the remote action
This is accurate.
ccrz.ccLog buffers log entries during execution.
Calling the close() method:
- Flushes the log
- Finalizes the log entry correctly
Failing to call close() can result in:
- Incomplete logs
- Lost or malformed logging data
This is a documented guideline used by the core B2B Commerce product.

✅ C. No calls to ccrz.ccLog can be made before cc_CallContext.initRemoteContext is executed
This is accurate.
cc_CallContext.initRemoteContext establishes:
- Execution context
- User/session details
- Request scope
Logging before this initialization:
- Lacks required context
- Can cause incorrect or missing log metadata
Salesforce enforces this ordering internally, making this a key exam point.

Why the other options are incorrect
❌ A. Items or data within computational intensive loops should be logged
This is explicitly discouraged.
Logging inside intensive loops:
- Hurts performance
- Produces excessive log volume
Core B2B Commerce avoids this pattern.

❌ D. It is okay to log any data on the server that is already logged on the client side
This violates logging efficiency and data minimization principles.
Core guidelines avoid:
- Duplicate logs
- Redundant data
Client-side logging does not justify server-side duplication.

Exam tip 🧠
When you see logging guidelines in B2B Commerce:
- Think performance
- Think context initialization
- Think clean log lifecycle (open → log → close)
Avoid answers that promote excessive or redundant logging.

Reference
Salesforce B2B Commerce Developer Guide
Salesforce Docs: CCRZ Logging Best Practices

Explanation:

In the classic Salesforce B2B Commerce for Visualforce (CloudCraze-based framework, still relevant to the B2B-Commerce-Developer / AP-202 exam), logic providers (classes in the ccrz namespace like ccrz.ccLogicProduct, ccrz.ccLogicCart, etc.) handle specific business logic operations (e.g., validation, calculations, data manipulation) invoked during API calls or storefront processes.

To customize or extend this logic:
- Extend the relevant logic provider class (e.g., global virtual class MyCustomLogicProduct extends ccrz.ccLogicProduct { ... }).
- Override the doLogic method — This is the primary entry point method that contains the core business logic execution. By overriding doLogic(Map<String,Object> inputData), you can:
  - Modify inputs/outputs.
  - Add custom validation or calculations.
  - Call super.doLogic() to invoke the base behavior (recommended for extensions rather than full replacement).
  - Return updated data or throw exceptions as needed.

After overriding, register your custom class in CC Admin > Storefront > Configuration Settings (or via logic provider mapping) to replace/override the default one.

Why not the others?
B. process — Not a standard override method in ccrz logic providers. (Some newer sfdc_checkout or extension classes use process, but not for classic logic providers.)
C. doAction — Not used in logic providers; more common in other frameworks or unrelated contexts.
D. fetch — Typically a service method (e.g., in ccrz.ccServiceXXX classes for data retrieval), not the logic execution override.

Reference:
B2B Commerce for Visualforce Developer Guide: Sections on extending logic providers (ccrz.ccLogicXXX classes) and overriding doLogic for custom behavior in API flows (e.g., product fetch, cart add, pricing logic).
This question is a staple in B2B-Commerce-Developer (AP-202) exam dumps and practice tests (2022–2025 versions). While some older/erroneous dumps list conflicting answers (e.g., doAction or process), the majority and most consistent reliable sources (including explanations tying doLogic to business logic execution in logic provider classes) point to A. doLogic as correct for the classic framework's logic extensions.

This approach is key for customizing backend logic in B2B Commerce storefronts without altering managed package code, such as adding custom rules during cart operations or product processing.

Explanation:

When troubleshooting unexpected UI behavior in a custom Lightning Web Component (LWC) within a Salesforce B2B Commerce storefront, the most effective approach is to use Debug Mode combined with browser developer tools. Debug Mode ensures that Lightning components load in an unminified state, making the JavaScript code easier to read and debug. This is crucial because, by default, Salesforce minifies component code in production, which obscures variable names and makes debugging nearly impossible.

Steps involved:
- Enable Debug Mode for the storefront user: This is done in Salesforce Setup under Debug Mode for Lightning Components. Once enabled, the user’s session will load LWCs in a readable format.
- Log in to the storefront as that user: This ensures the debug mode applies to the session where the issue is occurring.
- Use browser inspection tools (e.g., Chrome DevTools): Developers can inspect DOM elements, monitor network requests, and set breakpoints in the LWC JavaScript code. This allows them to trace execution flow, identify rendering issues, and confirm whether data binding or event handling is working correctly.

Why the other options are incorrect:
B. Load the LWC in VS Code and attach to session → Not supported. Debugging LWCs happens in the browser, not directly in VS Code.
C. Enable debug logs in Setup → Debug logs capture server-side Apex execution, not client-side LWC rendering issues.
D. Ask Salesforce support → Support can help with platform issues, but custom LWC debugging is the developer’s responsibility using Debug Mode and browser tools.

Thus, the fastest and most accurate way to investigate unexpected UI behavior in LWCs is Option A: enabling Debug Mode and using browser inspection/debugger tools.

Explanation:

When migrating from Aura to Lightning Web Components (LWC), Salesforce recommends an incremental approach rather than a "big bang" rewrite:

Why the correct statements are correct:
Statement A is correct because the Interoperability Model allows LWCs to sit inside Aura components. By migrating a single component first, a developer can validate the integration, assess the performance gains, and accurately estimate the effort required for the rest of the project.
Statement D is correct because components that are "purely representational" (meaning they mostly display HTML and CSS with minimal logic) are the easiest to port. These are often referred to as Leaf Components. Starting here provides a low-risk way to build out your library of base components in the new framework.

Why other options are incorrect:
B. Start with migrating trees of components → This is the opposite of the recommended strategy. Because LWCs cannot contain Aura components, migrating the "top" of a tree (a parent component) forces you to also migrate every single child component in that tree simultaneously, which increases complexity and risk.
C. Force all developers to write any new components using LWC → While LWC is the modern standard, "forcing" a specific tool without considering the specific use case (e.g., if a feature is only supported in Aura) is a management policy, not a technical migration guideline for the code itself.

Reference: Migrate Aura Components to LWC | Salesforce Developer Guide

Explanation:

When you set the target value of lightning__FlowScreen in the metadata configuration of a Lightning Web Component (LWC), you are explicitly telling Salesforce that this component is designed to be used inside Flow screens. This unlocks specific behaviors that make LWCs powerful tools for customizing guided user experiences.

Replace standard functionality in flows and subflows (A)
By registering an LWC with the lightning__FlowScreen target, developers can override or extend the default Flow screen functionality. For example, instead of using a standard Flow input component (like text fields or picklists), you can provide a custom LWC that implements specialized UI or logic. This allows you to tailor the Flow experience to meet unique business requirements, such as integrating external services or applying advanced validation rules.

Use in guided user experiences to gather input (C)
Flows are designed to guide users step-by-step through processes. With lightning__FlowScreen, LWCs can be dropped directly into Flow screens to collect user input, display dynamic content, or interact with Flow variables. This makes LWCs a natural fit for building rich, interactive guided experiences such as onboarding, troubleshooting, or checkout flows.

Why the other options are incorrect:
B. Drag onto a page in Lightning App Builder → That requires the lightning__AppPage, lightning__RecordPage, or lightning__HomePage targets, not lightning__FlowScreen.
D. Automatically generates configuration properties → Not true. Developers must explicitly define configuration properties in the LWC’s metadata file; they are not auto-generated.

Reference:
Salesforce Developer Guide: Lightning Web Components in Flow Screens explains how lightning__FlowScreen enables LWCs to be used in Flows for input and custom functionality.

Explanation:

In Salesforce B2B Commerce for Visualforce, Price Groups allow you to categorize users and apply specific price lists based on dynamic criteria (like a user’s department, region, or loyalty tier).

The Hook Method: The ccrz.cc_hk_Pricing hook is the architectural "switch" for pricing logic. Specifically, the bestPriceGroup method within this hook is designed to be overridden.

Dynamic Resolution: By extending this hook, a developer can write custom Apex to evaluate the current cc_CallContext and return the appropriate Price Group ID dynamically at runtime. This overrides the default behavior, which usually relies on a static assignment on the Account or User record.

Why other options are incorrect:
A. Overriding the ccLogicProductPrice class: Logic classes handle the "how" of price calculation (e.g., volume discounts) rather than the "who" (the Price Group assignment).
B. Using contract pricing: This is a configuration-based approach where Price Lists are assigned to Accounts. It is considered "declarative" rather than a "dynamic" programmatic setting.
C. Extending the ccApiPriceList API: The ccApi classes are entry points for data requests; they are not intended to be extended to change the core resolution logic of the framework.

Reference:
Logic for Selecting a Price Group | B2B Commerce Developer Guide

Explanation:

Page Includes are a Content Management System (CMS) feature in B2B Commerce (Business Manager) used to embed reusable content blocks into pages or templates.

A. Standard Visualforce controls such as apex:form should not be used within a page include: This is accurate and a key best practice. Page Includes are designed for static or simple dynamic content (using merge fields). They are rendered in a different context than the main page. Using Visualforce form tags or components that rely on view state (apex:form, apex:commandButton) inside a Page Include can cause view state conflicts, broken functionality, and hard-to-debug issues. Dynamic logic should be handled in the main page's controller or via JavaScript.

C. Page Includes can be configured as Body Includes Begin: This is accurate. When adding a Page Include to a page or template in Business Manager, you specify its position. Body Include Begin is one of the standard position options, which places the include's content at the beginning of the main content body area. Other positions include Body Include End, Header Include, Footer Include, etc.

Why the other options are incorrect:
B. Page Includes must be assigned to an OOTB Page, i.e. Home, Product Detail, etc., and enabled: This is inaccurate. Page Includes are not limited to Out-Of-The-Box (OOTB) pages. They can be assigned to:
- OOTB Pages (e.g., Home, Product Detail)
- Custom Subscriber Pages (CC Pages)
- Layout Templates
- Specific page instances via their URL.
The statement is too restrictive; their assignment is flexible.

D. If a controller is used for an included page, then a merge variable must be present on the page: This is inaccurate or misleading. First, Page Includes themselves do not have their own Visualforce controllers in the traditional sense. They are content snippets that can contain merge fields (e.g., {{CurrentPageName}}) that are resolved by the parent page's context or system properties. The requirement for a merge variable is not a rule. If you are referencing a custom property from the parent page's controller, that property must be exposed to the Visualforce markup, but this is not described by this option's phrasing. The statement as written is not a standard, documented rule for Page Includes.

Key Reference/Concept:
- Purpose of Page Includes: Reusable HTML/Visualforce snippets for banners, disclaimers, promotional content, scripts, etc.
- Positions: Body Include Begin, Body Include End, Header Include, Footer Include, etc., control where the snippet is injected.
- Content: Primarily static HTML, CSS, JavaScript, and simple merge fields. Avoid complex Visualforce components.
- Contrast with Subscriber Pages: Page Includes are content blocks within pages. Subscriber Pages are full pages.

Exam Takeaway: Remember that Page Includes are for simple, reusable content snippets. Key rules: 1) Avoid Visualforce forms/components inside them, and 2) They are placed using configurable positions like "Body Includes Begin". They are not restricted to OOTB pages.

Explanation:

The Shadow DOM is a core web standard that Lightning Web Components (LWC) rely on to provide encapsulation and security. Salesforce uses it to ensure components are modular, predictable, and safe.

A. It encapsulates the internal document object model (DOM) structure of a web component:
This is one of the primary purposes of the Shadow DOM.
The Shadow DOM creates a private DOM tree for the component.
Internal markup and styles:
- Don’t leak out
- Aren’t affected by external CSS or DOM changes
This prevents style collisions and DOM conflicts between components.
Encapsulation is fundamental to how LWCs work.

B. It allows components to be shared while protecting them from being manipulated by arbitrary code:
This is also correct.
Shadow DOM enforces component boundaries.
External scripts or components:
- Can’t directly reach into a component’s internal DOM
- Can only interact through public APIs (@api)
This enables:
- Secure reuse of components
- Safer execution in large applications like Salesforce
This aligns directly with Salesforce’s security and stability goals.

Why the other options are incorrect:
C. It allows direct access to the document object model of the component:
Shadow DOM does the opposite.
It restricts direct access to internal DOM elements.
Developers must use controlled APIs or template queries.

D. It allows older JavaScript libraries to manipulate the tagging structure:
Older libraries often expect global DOM access.
Shadow DOM intentionally prevents this.
This is why some legacy libraries don’t work well with LWCs.

Exam tip 🧠
When you see Shadow DOM, think:
- 🔒 Encapsulation
- 🧩 Component isolation
- 🛡️ Protection from external code
Avoid answers that suggest direct DOM access or legacy library manipulation.

Reference:
Salesforce Lightning Web Components Developer Guide
Trailhead: Understand Shadow DOM in Lightning Web Components

Explanation:

In Salesforce B2B Commerce on Lightning Experience (LEX/LWR-based storefronts), the checkout flow includes an inventory validation step to check product availability before proceeding (e.g., during the "Check Inventory" action in the checkout flow). To override or customize this behavior—such as integrating with an external inventory system, custom logic for reservations, or bypassing/altering standard checks—a developer must implement the sfdc_checkout.CartInventoryValidation interface.

This interface (in the sfdc_checkout namespace) requires implementing the validateCartInventory method (or similar entry point), which receives the cart/checkout context and returns an sfdc_checkout.InventoryStatus (e.g., SUCCESS, OUT_OF_STOCK, etc.).
After implementation, register the Apex class as a RegisteredExternalService record (via Workbench or setup tools) and map it to the store's checkout integrations (Commerce Setup > Checkout > Integrations or via flow configuration).
This hook allows full control over inventory validation during checkout, similar to other sfdc_checkout extensions (e.g., CartPriceCalculations, CartTaxCalculations).

Why not the others?
A. sfdc_commerce.ValidationCartinventory — No such interface exists in the sfdc_commerce or sfdc_checkout namespaces.
B. sfdc_commerce.CartinventoryValidation — Incorrect namespace; the checkout-specific interfaces are under sfdc_checkout.
C. sfdc_checkout.InventoryCartVvalidation — Typo/misspelled (extra "V" in "Vvalidation"); the correct spelling is CartInventoryValidation.

Reference:
Salesforce Developer Documentation: sfdc_checkout Namespace — Lists CartInventoryValidation for custom inventory checks in checkout.

Explanation:

When using Data Loader (or any data export tool), the data retrieved is subject to the user's field-level security (FLS) and object permissions. The Data Loader operates under the permissions of the logged-in user.

Why it's correct:
Even if the "Select All Fields" button is clicked, Data Loader will only include fields in the export that the current user has at least "Read" access to. If the developer's user profile or permission set does not grant Read access to the specific CustomField__c, the field will be included in the CSV (because "Select All Fields" selects it at the metadata level), but all of its values will be empty/null in the output. The header is present, but the data is masked due to lack of permissions.

Why the other options are incorrect:
A. The developer does not have the correct JDK that is recommended by Salesforce and this is known to cause issues with exporting custom attributes: This is a red herring. While using a supported JDK is good practice, JDK version issues typically cause connection failures or runtime errors, not the specific symptom of a field header being present with empty values. This symptom is classic for a permissions issue.

B. The developer does not have access to the object's metadata: This is too broad and imprecise. The developer clearly has some access to the object because they were able to launch Data Loader and select it, and other fields were exported. The problem is specific to the field-level permission, not the object-level metadata access (which would prevent seeing the object or field at all in the picklist).

C. The field is not populated: This is a possibility but not the root cause the question is looking for, given the phrasing. If the field were simply not populated, the developer would see blank values, which matches the symptom. However, the question implies the developer expects data to be there. More importantly, the most common administrative reason for a field appearing blank in an export despite being selected is insufficient FLS permissions. The exam tests on Salesforce security fundamentals.

Key Reference/Concept:
Field-Level Security (FLS): A core Salesforce security model. Users can have different levels of access (None, Read, Edit) to individual fields, independent of their access to the object.

Data Visibility: Tools like Data Loader, SOQL queries in the Developer Console, and reports all respect the running user's FLS and sharing rules. Data is hidden if the user lacks read permission.

Troubleshooting: To resolve this, an administrator must modify the user's Profile or Permission Set to grant "Read" access to the custom field.

Exam Takeaway: When you see a scenario where a field header appears in an export/query but values are blank/missing, the first and most likely cause to check is Field-Level Security (Read permission). This is a fundamental security principle tested on Salesforce platform exams.