Free B2B-Commerce-Developer Practice Test Questions 2026

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.

Explanation:

This question is asking specifically about the fastest route for a developer to set up a Salesforce B2B Commerce store. Speed is the key qualifier here, not flexibility, customization, or learning value.

In Salesforce B2B Commerce, the fastest way to get a store up and running is to reuse an existing store configuration rather than building one from scratch.

That is exactly what importing a previously exported store archive does.

🔑 Why importing a store archive is the fastest approach:

A store archive contains a complete snapshot of a B2B Commerce store, including:
- Store configuration
- Catalog structure
- Pricing setup
- Templates and themes
- Checkout configuration
- CMS references
- Settings already wired together correctly

By importing an archive, a developer can:
- Spin up a fully functional store in minutes
- Avoid manual configuration steps
- Skip repetitive setup tasks
- Ensure consistency across environments (dev, QA, UAT)

This method is widely used for:
- Rapid environment provisioning
- Developer sandboxes
- CI/CD pipelines
- Demo or test stores

From an exam perspective, Salesforce considers archive import the quickest and most efficient setup method when one is available.

❌ Why the other options are incorrect:

❌ A. Set up B2B Commerce on Lightning Experience manually:
Involves many manual steps:
- Enable features
- Configure settings
- Create catalogs and pricing
Time-consuming and error-prone
Definitely not the fastest

❌ B. Create a new store in the Commerce app:
Faster than manual setup, but still requires:
- Post-creation configuration
- Additional setup steps
Slower than importing a fully configured store archive

❌ D. Use SFDX setup scripts:
Powerful for automation and repeatability, but requires:
- Script creation
- Execution
- Debugging
Not as fast as a one-step archive import

📚 Salesforce References:
Salesforce B2B Commerce Developer Guide: Exporting and Importing Stores
Salesforce Help: Move B2B Commerce Stores Between Orgs
Trailhead: Set Up a B2B Commerce Store

Explanation:

In Salesforce B2B Commerce for Visualforce (the Aura-based implementation central to the B2B-Commerce-Developer exam), API-based record creation (e.g., via @RemoteAction methods, internal Commerce APIs, or programmatic inserts of entities like products, carts, orders, addresses, etc.) is generally handled in the service layer.

The service layer consists of classes in the ccrz namespace, such as ccrz.ccServiceProduct, ccrz.ccServiceCart, ccrz.ccServiceOrder, etc.
- Each entity has a dedicated service class responsible for CRUD operations (Create, Read, Update, Delete).
- Creation logic (inserts, population of fields, validation, and related operations) is encapsulated in methods like create(), upsert(), or internal handlers within these service classes.
- When you perform API-based creation (e.g., through remote actions or extension points), the framework routes the operation through the appropriate service class for that entity, ensuring consistent data handling, field mapping, and business rules.

This separation keeps the service layer as the central point for data manipulation, while extension hooks, logic classes, etc., handle augmentation or specific behaviors.

Why not the other options?

A. In the methods available in extension hooks:
Extension hooks (e.g., cc_hk_* classes) are for pre/post-processing, augmentation, or overrides (e.g., modifying data before/after service calls). They do not handle the core record creation itself — they extend or intercept it.

C. Data creation is not allowed:
Incorrect — B2B Commerce allows programmatic/API-based creation of many records (carts, orders, addresses, custom entities, etc.) via services and remote actions.

D. Logic classes that implement the business logic for create operations:
Logic classes (ccrz.ccLogic*, e.g., ccLogicCartPricing, ccLogicProductPricing) handle business calculations (pricing, promotions, inventory rules, etc.), not the actual record insertion or creation. Creation remains in the service layer.

Key References & Exam Consensus:

B2B Commerce Developer Guide (secured, but referenced in dumps): Service classes handle entity interactions, including create/insert operations.

Explanation:

In B2B Commerce Classic (CloudCraze), when you write custom JavaScript to call an Apex @RemoteAction, you leverage the framework's built-in remoting utility to ensure the proper context (like Storefront name and Portal User) is passed to the server.

CCRZ.RemoteInvocation (D):
This is the base JavaScript object provided by the managed package. By extending or using this object, your custom code inherits the ability to automatically wrap requests with the cc_RemoteActionContext.

Consistency:
Using this object ensures that your calls remain consistent with the standard B2B Commerce event loop and security protocols.

Common Pattern:
Developers typically define a JavaScript class that extends CCRZ.RemoteInvocation to handle communication between the Handlebars templates/Backbone views and the custom Apex controllers.

Why the others are incorrect:

A & B: CCRZ and CCRZ.cc are global namespaces used to store configuration, utility functions, and models, but they are not the specific objects designed for extending remoting logic.

C. CCRZ.cc_CallContext: This is a server-side Apex class used to track the session state. While it has a JavaScript representation, it is used for data storage, not as a base class for executing remote actions.

Reference:
Salesforce B2B Commerce Developer Guide: Section on Custom Remote Actions in B2B Commerce Classic.
CloudCraze Documentation: Overview of the RemoteInvocation JS class structure.

Explanation:

In Salesforce B2B Commerce, when importing data using a CSV file format (e.g., for products, categories, or other store entities via the Commerce import tools or Data Loader for custom fields), only certain custom field data types are fully supported for bulk import operations.

From official Salesforce documentation and consistent exam patterns:

The supported data types for custom fields in CSV imports include (but are not limited to) checkbox, currency, date, date/time, email, number, percent, phone, picklist, text, text area, text area (long), time, URL, etc.

Specifically for the options given:
- Text Area (Long) — Supported (long text fields can hold up to 131,072 characters and are importable via CSV).
- Lookup Relationship — Supported (lookup fields can be imported by providing the related record ID, external ID, or name in the CSV column; the importer resolves the relationship).
- Currency — Supported (currency fields are importable, with values handled in the store's currency context or converted appropriately).

Why not the other options?

B. Picklist (Multi-Select):
While standard picklist (single-select) is supported, multi-select picklist is not reliably supported for CSV import in B2B Commerce contexts (or may require special formatting like semicolon-separated values, but it's often excluded or problematic in bulk imports for Commerce entities). Official sources and exam consensus exclude it here.

D. AddressAddress (compound field type):
Not supported for direct CSV import as a custom field in this context. Address fields require structured sub-components (street, city, etc.), and the Commerce CSV import process does not handle compound address fields natively for custom fields.

Key References:
Salesforce Help: CSV File Format for Importing Product Data to B2B Stores — Lists supported types including checkbox, currency, date/time, email, number, percent, phone, picklist, text, text area, text area (long), etc. (implies long text and currency are ok; lookups via ID resolution).

Explanation:

During B2B Commerce development, a developer most commonly investigates errors using browser developer tools (such as Chrome DevTools or Firefox DevTools). These tools allow you to:

Inspect JavaScript errors in the Console
Debug Lightning Web Components (LWC) and custom JavaScript
Analyze network requests (API calls, OCAPI/SCAPI responses, REST errors)
Inspect HTML/CSS rendering issues
View request/response payloads and HTTP status codes

Since Salesforce B2B Commerce storefronts run in the browser and rely heavily on client-side JavaScript and APIs, browser dev tools are essential for day-to-day debugging.

Why the other options are incorrect

❌ A. Commerce Diagnostics Event Logging
This is primarily used for operational monitoring and troubleshooting in production, not for hands-on development debugging. It’s more admin/support-focused than developer-focused.

❌ B. Checkout Flow Log
Checkout logs help analyze checkout process behavior, but they are not a general-purpose debugging tool and are too narrow for investigating most development errors.

❌ C. Support cases
Support cases are used after issues occur in deployed environments, not as a development-time debugging tool.

Exam tip 🧠
If a question asks about:

“during development”
“investigate errors”
“debug storefront behavior”

👉 The correct answer is almost always browser developer tools.

Reference
Salesforce Help & Training:
Trailhead → Debug JavaScript with Browser DevTools
Salesforce B2B Commerce Developer Guide (Storefront debugging sections)

Explanation:

In Salesforce B2B Commerce, a Cart Item with Type = Charge (where the Type field on the CartItem object is "Charge") represents additional fees applied to the cart or a specific cart delivery group. Common examples include shipping charges, handling fees, taxes, or other surcharges.

Creation timing (A is correct)
During the checkout process, after the buyer selects a shipping method (or the system determines it), the shipping integration (standard or custom, via the Cart Delivery Group Method) is invoked. This integration calculates shipping costs and creates one or more Cart Items of Type Charge (with ChargeType often set to "Shipping" or similar) linked to the relevant CartDeliveryGroup. This happens specifically after the shipping integration step, not freight (freight is typically a subset or related to shipping but not the standard term used here).

Note: Some exam dumps incorrectly swap shipping/freight or suggest freight, but the accurate statement in standard B2B Commerce contexts (and most consistent across recent exam references) points to shipping integration.

Linked directly to a Cart Id (C is correct)
All CartItem records (including those with Type = Charge) have a direct lookup to the parent WebCart (via the CartId field). This ties the charge item to the specific active cart.

Why not the others?

B. It is created with the Cart Delivery Group Method after the freight integration — Incorrect.
While freight costs may be part of shipping calculations in some implementations, the standard Salesforce documentation and integration flow refer to shipping integration (not freight) for creating these charge items. Freight is not the precise term used in this context.

D. It is linked directly to a Catalog Id — Incorrect.
CartItem records do not have a direct lookup to Catalog (Catalog is associated with products via Pricebook/PricebookEntry). Charge-type items are not product-based and reference the Cart and often the CartDeliveryGroup, but not a CatalogId directly.

Reference
Salesforce Developer Documentation: CartItem Object — Confirms CartItem can be of type "Product" or "Charge" and links to Cart (WebCart).
B2B Commerce Developer Guide sections on Checkout Flow, Shipping Integration, and Cart Calculations — Describe how shipping integrations (via Cart Delivery Group Method) add charge-type cart items for fees like shipping.

Explanation:

This command correctly uses the sfdx force:data:tree:export command with the necessary parameters to export all Product2 records to a specified directory in a format compatible with later re-import.

Valid command structure
sfdx force:data:tree:export: The base command for exporting data in a hierarchical, relationship-preserving format (as a data plan).

-q "SELECT Id, Name, ProductCode, ... FROM Product2": The crucial -q flag allows you to specify a SOQL query (q for query) to select the exact records and fields you want to export. To get all Product data, you would write a comprehensive SOQL query selecting all necessary fields from Product2 and related objects. The placeholder -x export-demo in the option likely implies a pre-existing query file named export-demo.

-d /tmp/sfdx-out: The -d flag specifies the output directory where the exported .json files will be saved.

-p: The -p flag is for plan, which signals the export should generate a data plan file (plan.json) that defines the order for import, preserving relationships.

Why the other options are incorrect

B. sfdx force:data:tree:export -Product2 -all
This syntax is invalid. The force:data:tree:export command does not have a -Product2 or an -all flag. It requires either a SOQL query (-q) or a predefined configuration file.

C. sfdx force:data:tree:export -o Product2
This is incorrect and misleading. The -o flag in related commands like force:data:tree:import stands for order and is used to specify a plan file. It is not used to name an object for export. The command is missing the mandatory query (-q) or config file parameter.

D. sfdx force:data:tree:export -h
This command is simply requesting help (-h). It displays the usage instructions for the command but does not perform any export operation.

Key reference and concept
SFDX CLI Data Commands: For bulk data operations when Data Loader is unavailable, the sfdx force:data:* commands are the standard toolset for developers. The tree:export and tree:import commands are designed for moving complex, related data.

Importance of the SOQL query (-q)

The force:data:tree:export command is query-driven. You must specify the exact dataset via a SOQL query. For a complete export, your query would need to include all relevant fields.

Note on the bulk aspect
While tree:export is powerful for complex data, for a truly simple bulk export of a single object without complex relationships, sfdx force:data:soql:query -q "SELECT FIELDS(ALL) FROM Product2" -r csv > products.csv might be a simpler alternative. However, given the options presented and the command's capability, option A is the correct choice that aligns with the SFDX data command pattern for a structured export.

Exam takeaway
Know the key SFDX CLI commands for data operations. The force:data:tree:export command is the primary CLI tool for exporting relational data, and it requires a SOQL query (-q) to define the dataset. Memorizing flag purposes (-q for query, -d for directory, -p for plan) is essential.

Explanation:

In Salesforce Lightning (including Lightning Web Components used in B2B Commerce on Lightning), navigation between pages and components uses the NavigationMixin and PageReference objects. The type property in a PageReference specifies the page reference type, many of which use the standard__ namespace for core platform pages.

The three options that match standard page reference types are:

standard__app
Navigates to a standard or custom Lightning app (for example, Sales app or Service app). Example: { type: 'standard__app', attributes: { appTarget: 'standard__Sales' } }.

standard__component
Navigates to a custom Lightning component (Aura or LWC) that implements lightning:isUrlAddressable. Example: { type: 'standard__component', attributes: { componentName: 'c__myComponent' } }.

standard__pageNamed (standard__namedPage)
Navigates to a standard named page like home, chatter, or today. Example: { type: 'standard__namedPage', attributes: { pageName: 'home' } }.

Why not the others?

D. comm_loginPage
This is a commerce-specific page reference type used in B2B or B2C Experience sites and uses the comm__ namespace, not standard__. It is not considered a standard core Lightning page reference type.

E. standard__recordDetailPage
There is no valid page reference type called standard__recordDetailPage. The correct record-related types are standard__recordPage (for detail, edit, or related views) and standard__recordRelationshipPage. recordDetailPage is not a valid standard type.

Reference
Salesforce Developer Documentation: PageReference Types — Lists standard types including standard__app, standard__component, and standard__namedPage, along with others like standard__recordPage and standard__objectPage.
Lightning Aura Components Guide: PageReference Types — Confirms the same standard__ page reference types.