Salesforce-B2C-Commerce-Cloud-Developer Practice Test Questions

Explanation:

In Salesforce B2C Commerce SFRA, CSRF protection is implemented using middleware functions that intercept and validate requests before the controller logic executes. This is the most reliable and scalable way to protect against request forgery.

Why middleware is the correct place:

SFRA provides built-in middleware like csrfProtection.validateRequest and csrfProtection.validateAjaxRequest.
These are added directly to the middleware chain of a server.post() route.
This ensures that any POST request is validated for a CSRF token before any business logic runs.

Example implementation:

var server = require('server');
var csrfProtection = require('*/cartridge/scripts/middleware/csrf');

server.post(
'SubmitAddress',
server.middleware.https,
csrfProtection.validateRequest,
function (req, res, next) {
// Your form handling logic here
next();
}
);

❌ Why the other options are incorrect

A. In the controller function that displays the form This is where you generate the CSRF token using generateToken(), not where you validate it.

C. In the controller function that handles the submitted form While technically possible to call CSRFProtection.validateRequest() manually, SFRA best practices recommend using middleware instead.

D. In the model function that persists the form data Model functions should not handle request validation. That’s a controller-level concern.

Explanation:

In Salesforce B2C Commerce, when a shopper uses Storefront search, refinements (like "Newness") are not only controlled by the category where the product resides, but also by its parent categories in the search context.

In this case:

The "Clothing" category has the "Newness" refinement set correctly.

However, storefront search results are often scoped or filtered based on higher-level categories, like "New Arrivals" or "Women" in the navigation hierarchy.

If the "New Arrivals" category doesn't include the same Search Refinement (i.e., "Newness"), it will not appear when customers search and land on that category context.

This happens because refinements from parent categories must be explicitly configured, even if the child category is set up correctly.

❌ Why Other Options Are Incorrect:

A. Conflicting Search Refinement definitions
Not applicable — conflict isn’t causing this issue. It's about missing refinements, not conflicting ones.

B. Not set up for Women
While possible, the context of the question points to "New Arrivals" as the entry point for search results.

D. Not set up for Root Category
The root category is not relevant unless the search is scoped to it directly. That’s not the case here.

Explanation:

To ensure consistent order totals (including taxes) when using Open Commerce API (OCAPI), the taxation logic should be moved to the dw.ocapi.shop.basket.calculate hook. Here's why:

Key Points:
Purpose of dw.ocapi.shop.basket.calculate:

This hook is triggered whenever the basket is recalculated (e.g., adding/removing items, applying promotions, or updating shipping).

It ensures taxes, discounts, and totals are consistently applied before the order is finalized.

Why Not Other Options?

A. dw.ocapi.shop.order.validateOrder
Runs after basket calculation, during order submission—too late for tax adjustments.

C. dw.ocapi.shop.basket.afterPostShipment
Runs after shipping is applied, but taxes must be calculated before this stage.

D. dw.ocapi.shop.order.afterPOST
Runs after the order is placed—used for post-order processing (e.g., notifications), not tax logic.
Taxation Logic in calculate Hook:
Ensures taxes are always up-to-date with basket changes.

Example:
dw.ocapi.shop.basket.calculate = function (basket, calculationSteps) {
// Apply custom tax logic here
TaxMgr.calculateTax(basket);
};

Explanation:

In Salesforce B2C Commerce, when you have multiple sites (e.g., U.S. and Europe) sharing the same product catalog, but needing site-specific display logic — such as different certification logos — the best practice is to use site-specific custom attributes on the Product system object.

This allows each site to:

Define its own value for the same attribute (e.g., certificationLogo)
Display the appropriate logo on the product detail page based on the current site context
Avoid duplicating products or catalogs unnecessarily

Key characteristics of site-specific attributes:

They override the global value for a specific site
They are non-localizable (localizable attributes are for language/locale differences)
They are ideal for regional compliance, merchandising, or visibility rules

🔧 Example Implementation

Create a custom attribute on the Product system object:
ID: certificationLogo
Type: Image or String (URL to image)
Mark it as site-specific

Assign site-specific values in Business Manager:
For U.S. site: certificationLogo = /images/certA.png
For EU site: certificationLogo = /images/certB.png

Render in ISML:
< isif condition = " $ { pdict. Product. custom. certificationLogo } " >
< img src = " $ { pdict. Product. custom. certificationLogo } " alt = " Certification Logo " >
< / isif >

❌ Why the other options are incorrect

A. Localizable custom attribute on Certificate system object
Localizable attributes are for language differences, not site-specific logic. Also, Certificate isn’t a standard system object unless custom-defined.

B. Image custom preference on SitePreference Site preferences are global to the site, not tied to individual products.

D. Localizable custom preference on SitePreference Again, this is for localization, not product-specific logic.

Explanation:

The proper Open Commerce API (OCAPI) URL format for a sandbox environment (test.demandware.net) follows this structure:

Key Components of the URL:

Domain:
Sandbox domains use test.demandware.net (not .com or custom domains like www.test.com).

Site Path:
Includes the site name (/s/test-site/) to route the request to the correct sandbox site.

OCAPI Base Path:
Uses /dw/shop/ for storefront APIs (or /dw/data/ for data APIs).

API Version:
Explicitly specifies the version (e.g., v18_3) for backward compatibility.

Endpoint & Parameters:
Targets the products/M1355 endpoint with a client_id for authentication.

Why Option C is Correct?
Sandbox Domain: test.demandware.net
Site Context: /s/test-site/
OCAPI Path: /dw/shop/v18_3/products/M1355
Authentication: ?client_id=aaa...

Why Not Other Options?

A: Uses .com (invalid for sandbox) and lacks site path (/s/test-site/).
B: Uses www.test.com (invalid sandbox domain) and incorrect path (/sfc/shop/).
D: Lacks the site path (/s/test-site/) and uses www.test.com (invalid).

Explanation:

In Salesforce B2C Commerce, if a product is always available regardless of inventory levels, such as a digital gift voucher, the recommended way to manage its availability is to enable the "Perpetual" inventory flag.

🔄 What does the Perpetual flag do?
Tells the system to ignore stock levels for the product.

The product will always appear as in stock and available to sell, even if no stock records exist.

Commonly used for:
Digital goods (e.g., gift cards, e-books)
Services
Unlimited inventory products

📍 How to Enable in Business Manager:
Go to:
Merchant Tools > Products and Catalogs > Inventory > Inventory Lists

Find the inventory record for the gift voucher product.

Check the "Perpetual" flag.

Save.

Once enabled, SFCC will treat this item as always in stock, no matter what.

❌ Why the Other Options Are Incorrect:

B. Check the Available to Sell (ATS) flag for the product set
ATS is a calculated value (not a flag) based on current stock minus allocations. You cannot "check a flag" to force availability.

C. Set StockLevel = maxAllocation for the product
This will still cause ATS to hit zero when allocated. Doesn't guarantee perpetual availability.

D. Manually set the inventory to a high number
This is a temporary workaround, not a scalable or reliable solution. Also introduces risk if stock syncs from external systems.

Explanation:

In the given ISML loop, the developer should reference the current product object directly using the variable name defined in the var attribute (product). Here’s why:

Key Points:

Loop Structure:
< isloop items = " $ { pdict. Basket. products } " va r= " product " status = " loopstatus " >
< ! -- Current product is accessible via 'product' -- >
$ { product. ID } < ! -- Example: Accessing the product ID -- >
< / isloop >

var="product" defines the variable name for the current iteration’s product.

Why product (Option A)?

The var attribute explicitly sets the reference name (product).
Directly using product (e.g., ${product.ID}) is the cleanest and correct approach.

Why Not Other Options?

B. pdict.Basket.products{loopstatus}
Invalid syntax. loopstatus is a counter (index), not a key.

C. loopstatus.product
loopstatus only tracks iteration metadata (e.g., index, first, last), not the object itself.

D. pdict.product
pdict contains the template’s root objects, not loop variables.

Explanation:

When a merchant begins shipping to a new country like Italy, and tax is not being calculated correctly, the most likely cause is that no tax jurisdiction has been defined for that country in Business Manager.

What is a Tax Jurisdiction?
A tax jurisdiction defines the geographic area (e.g., country, state, zip) where specific tax rules apply. It’s used to map customer shipping addresses to the correct tax rate.

If Italy is not configured as a jurisdiction:

The system cannot match the shipping address to a tax rule
It defaults to no tax, or a fallback jurisdiction (if configured)
Tax rates will not be applied correctly

🔧 How to Fix It
Go to Business Manager > Merchant Tools > Ordering > Taxation
Open the Tax Jurisdictions tab
Create a new jurisdiction for Italy
Set the country code to IT
Define applicable tax rates under the Tax Rates tab
Ensure products and shipping methods are assigned to the correct Tax Class

❌ Why “Tax Locale is configured wrong” is less likely
Locales affect language, currency, and formatting, not tax calculation directly. While locale misconfiguration can affect display, it won’t prevent tax from being calculated — unless it’s tied to a missing jurisdiction.

Explanation:

To display washing instructions for a clothing product that come from a Product Information Manager (PIM) and need to be localized on the storefront, the best solution is to create a custom product attribute and mark it as localizable.

Why This Works:

- A custom attribute allows storing product-specific data like washing instructions.
- Marking the attribute as localizable enables different values for each language/locale.
- Localized values can be imported from the PIM or entered in Business Manager.
Where to Configure:

Business Manager > Administration > System Object Types > Product > Attribute Definitions
1. Add a new attribute (e.g., washingInstructions)
2. Check the box for "Localizable"
3. Assign it to the appropriate attribute group
4. Enter translations for each locale manually or via import

Why Other Options Are Incorrect:

A. Set the product system object type as localizable: Only individual attributes can be made localizable, not the entire system object.
B. Add a resource file for every locale: Resource bundles are for static UI text, not dynamic product data.
D. Add a custom attribute for each locale: This is inefficient and unscalable. Use one localizable attribute instead.

Explanation:

When working with SFRA (Salesforce Reference Architecture) in Salesforce B2C Commerce, form definitions (like newsletter.xml) define input fields for structured form handling. To retrieve the form object (in JSON form), you use:

Server.forms.getForm('FormID')

In this case, the form file is named newsletter.xml, so the correct ID to use is "newsletter" (not prefixed with dwfrm_ — that prefix is used for HTML name attributes, not in JavaScript).

🔍 Why This Works:

Server.forms.getForm('newsletter') retrieves the JSON representation of the form defined in newsletter.xml.

This JSON object contains the field values and metadata like validity, errors, etc.

❌ Why the Other Options Are Incorrect:

A. Server.form.getForm('dwfrm_newsletter')
Typo in form — should be forms. Also, dwfrm_ is used in the frontend, not when referencing form definitions in server-side JS.

B. Server.form.getForm('newsletter')
Again, form is incorrect — it should be forms.

D. Server.forms.getForm('dwfrm_newsletter')
Incorrect use of dwfrm_ prefix. You only use the actual file name (without prefix).