B2B-Commerce-Developer Practice Test Questions (2026)

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.

Explanation:

The most direct and reliable method to determine if the current context user is a guest user in an Apex class is to use the standard Salesforce UserInfo.getUserType() method.

Why it is correct
This method returns a string indicating the user's type. For a Site Guest User (which is the user type for B2B Commerce storefront guests), it returns Guest. This is a core Salesforce system method that works in any execution context, including within the B2B Commerce framework.

How to use it
Boolean isGuest = UserInfo.getUserType() == 'Guest';

Why the other options are incorrect

A. ccrz.cc_CallContext.currUser.isGuest
This is incorrect. While the ccrz.cc_CallContext class is central to B2B Commerce for storing request-specific data such as the current cart, storefront, and user info, the currUser property is of type ccrz.cc_bean_contact and does not have a field or property named isGuest. It contains contact details, not platform user type flags.

B. ccrz.cc_CallContext.isGuest
This is incorrect. The ccrz.cc_CallContext static class does not expose a public static Boolean property or method named isGuest. You cannot check guest status directly through this context class.

D. UserType
This is an incomplete or invalid reference. While UserType is a field on the User object, you cannot directly access it for the current user without a SOQL query. Using a query such as SELECT UserType FROM User WHERE Id = :UserInfo.getUserId() is inefficient and unnecessary when UserInfo.getUserType() provides the value directly.

Key reference and concept

B2B Commerce Guest Users
When a user browses a B2B Commerce storefront without logging in, they are assigned a Salesforce Site Guest User license. Identifying this is crucial for logic that behaves differently for authenticated users versus anonymous shoppers, such as pricing visibility or checkout enforcement.

Standard vs. custom context
Always prefer standard Salesforce platform methods like the UserInfo class for platform-level metadata. The B2B Commerce cc_CallContext is intended for framework-specific context such as storefront, locale, and cart, not for fundamental platform user attributes.

Execution context
UserInfo methods work in all execution contexts including Apex triggers, controllers, and services. Relying on B2B Commerce context objects may only be valid within the lifecycle of a storefront request.

Exam takeaway
Distinguish between platform user identification using the UserInfo class and B2B Commerce runtime context using cc_CallContext. For questions about determining user type, license, profile, or user ID, the UserInfo class is almost always the correct answer.

Explanation:

Why it is correct
Lightning Out is a powerful feature that allows you to run Lightning web components outside of Salesforce servers. Whether you want to display a Salesforce component on a site hosted on Heroku, AWS, or an internal corporate portal, Lightning Out provides the necessary JavaScript libraries to initialize the Lightning orchestrator in that external container.

It works by creating a small dependency app (a .app file) that tells Salesforce which components and dependencies to bundle.

You then include a script tag on your external page that calls $Lightning.use() to initialize the app and $Lightning.createComponent() to render the LWC into a specific DOM element.

Why other answers are incorrect

A. Slot elements
These are a standard Web Component feature used for content projection, allowing markup to be passed from a parent component into a child component. They are used within Lightning Web Component development, not for exposing components to external web containers.

B. Heroku
While Heroku is a platform where you might host a web container that uses Lightning Out, Heroku itself is a Platform-as-a-Service and not a technique or API for exposing Salesforce components.

D. Lightning Canvas
Now generally referred to as Force.com Canvas, this technology embeds an external web application inside the Salesforce UI. It does the opposite of Lightning Out and does not expose Salesforce components to the outside world.

Reference
Salesforce Developer Guide: Use Lightning Components in External Sites (Lightning Out)