Explanation

In Salesforce B2C Commerce (SFCC), to allow customers to filter products on the storefront by a particular attribute, the attribute must be exposed as a Search Refinement Definition.

A Search Refinement Definition (configured in Business Manager under Merchant Tools > Search > Search Refinements) maps a product attribute (e.g., brand, size, color, or a custom attribute) to a filterable refinement that appears on the storefront. When a refinement definition is created and associated with the attribute, the storefront displays it as a filter option (in the refinement bar), letting shoppers narrow results by that attribute.

This is the purpose-built mechanism for enabling storefront filtering — so adding a new Search Refinement Definition is the correct and necessary step, making option A correct.

Why the Other Options Are Incorrect

B. Set the attribute as Searchable.
– Marking an attribute as searchable means its value is indexed and searchable (i.e., it can be matched by search queries). However, being searchable does not automatically make the attribute appear as a filter/refinement on the storefront. Searchability and refinement (filtering) are separate concerns. To enable filtering, you need a Search Refinement Definition, not merely making the attribute searchable. So this option does not achieve the requirement.

C. Change the `productsearchrefinebar.isml` template.
– Modifying the refinement bar template (`productsearchrefinebar.isml`) affects the presentation/layout of the refinement bar — but it does not create the refinement itself. Without a Search Refinement Definition, there is nothing for the template to display as a filter. Changing the template alone would not enable filtering by the new attribute. The definition is what makes the attribute filterable; the template only renders whatever refinements are defined.

Reference

Salesforce B2C Commerce documentation — Search Refinements (Search Refinement Definitions) in Business Manager (Merchant Tools > Search > Search Refinements), covering how to expose product attributes as filterable refinements on the storefront.

Explanation

To make a Business Manager extension appear in the Business Manager UI, two things are required:

1. Add the cartridge to the Business Manager cartridge path.

Business Manager has its own cartridge path (configured for the Business Manager site under Administration > Sites > Manage Sites > Business Manager > Cartridges). For a Business Manager extension cartridge to load and display its menu items/UI, it must be added to the Business Manager cartridge site path — not the storefront cartridge path. This makes Business Manager aware of the extension and renders its menu entries.

2. Grant the appropriate roles and permissions.

Even when the extension cartridge is loaded, the extension's menu/options will not be visible to a user unless that user has the appropriate roles and permissions assigned to view the Business Manager extension. Business Manager extensions define permissions, and users must be granted those permissions for the extension options to appear. Without the correct roles/permissions, the extension remains hidden.

Together, these two steps — adding the cartridge to the Business Manager cartridge path and assigning the appropriate roles/permissions — ensure the extension option shows up in Business Manager. This matches option A.

Why the Other Options Are Incorrect

B. Add `custom_bm_extension` to the cartridge path under Storefront cartridge site path AND add `plugin_bm_extension` to the cartridge path under business manager cartridge site path.
– This option adds the extension cartridge to the Storefront cartridge path, which is irrelevant for a Business Manager extension. Business Manager extensions must be added to the Business Manager cartridge path, not the storefront path. Additionally, it omits the roles/permissions step, which is required for the extension to be visible to a user. So this option includes an unnecessary/incorrect step and misses a required one.

C. Add the appropriate roles and permissions to the user to view the business manager extension AND activate a new code version for the Business Manager site.
– Granting roles/permissions is correct, but activating a new code version is not the required second step for making a Business Manager extension appear. Activating a code version is a deployment action; the extension cartridge must be added to the Business Manager cartridge path for it to load. Since this option omits adding the cartridge to the Business Manager cartridge path, the extension would not appear — so it is incorrect.

Reference

Salesforce B2C Commerce documentation — Business Manager Extensions (cartridge-based extensions), covering adding the extension cartridge to the Business Manager cartridge path and assigning roles/permissions so users can view the extension in Business Manager.

Explanation

In Salesforce B2C Commerce (SFCC), enabling a new locale for a storefront involves two distinct levels of configuration — a global step and a site-specific step:

1. Create and configure the locale under Global Preferences (organization-wide).

The locale itself is defined at the organization/global level. Under Administration > Global Preferences > Locales (Global Preferences section), the developer creates the locale (e.g., `fr_FR`, `es_ES`) and configures its settings (such as locale code, date/number formats, and related attributes). This makes the locale available to the organization. This is the global part of the setup.

2. Activate the locale in Site Preferences (site-specific).

Once the locale exists globally, it must be activated for the specific site where it will be used. Under Merchant Tools > Site Preferences > Locales (Site Preferences section), the developer activates (enables) the locale for that site. This makes the locale usable on the storefront for that particular site.

Only after both steps — global creation/configuration + site activation — will the locale be enabled in the Storefront. This two-level workflow matches option A exactly.

Why the Other Options Are Incorrect

B. Create, configure, and activate the locale under Global Preferences section.
– This option performs all steps under Global Preferences, including the activation. However, activation of a locale for the storefront is a site-specific action, not a global one. Creating/configuring the locale is global, but activating it must be done in Site Preferences for the relevant site. Doing everything globally would not activate the locale for the specific storefront site, so this option is incorrect.

C. Add an alias for the new locale and then create and configure the locale itself under Global Preferences section.
– While locale aliases exist in SFCC (mapping alternate locale codes to a primary locale), the requirement does not call for an alias — it calls for enabling a new locale. Adding an alias is an optional/separate concern (used when you want multiple codes to resolve to the same locale), not a required step for adding a new locale. This option also omits the site-specific activation step, so it does not fully enable the locale on the storefront.

Reference

Salesforce B2C Commerce documentation — Locales configuration in Business Manager, covering Global Preferences > Locales (creating/configuring locales organization-wide) and Site Preferences > Locales (activating locales for a specific site).

Explanation

To let customers filter products by intended activity (tennis, jogging, basketball, etc.), the developer needs to accomplish two things:

1. Store the "intended activity" data on products.

Since the current catalog does not contain this information, a new field must be added to products to hold it. In SFCC, this is done by creating a new Product custom attribute (e.g., `intendedActivity`) on the Product system object. The merchant then populates this attribute with values (tennis, jogging, basketball, etc.) for each product.

2. Make the attribute available as a filter (refinement) on the storefront.

For customers to filter products by this attribute in category/search results, the attribute must be exposed as a Search Refinement Definition. The developer adds a new Search Refinement Definition for the desired categories, mapping it to the new product attribute so it appears as a filterable option in the storefront.

Together, these two actions:

* Create a Product custom attribute → stores the intended-activity data.
* Add a Search Refinement Definition → exposes that data as a filter for customers.

This makes option A the correct answer.

Why the Other Options Are Incorrect

B. Create a new ProductRefinement custom attribute AND add a new Search Refinement Definition for the desired categories.
– There is no "ProductRefinement" custom attribute type in SFCC. The custom attribute is created on the Product system object (a Product custom attribute), not a "ProductRefinement" attribute. The term "ProductRefinement" is a fabricated/misleading attribute type. Since the first action is wrong, this option is incorrect.

C. Create a new Product custom attribute AND add a new viewtype in the storefront catalog settings.
– The first action (creating a Product custom attribute) is correct, but the second action is wrong. Adding a viewtype relates to image view types (image size/variant configuration), not to filtering/refinement. To allow filtering, the developer must add a Search Refinement Definition, not a viewtype. Viewtypes have nothing to do with enabling product filters, so this option does not meet the requirement.

Reference

Salesforce B2C Commerce documentation — Custom Product Attributes (Product system object) and Search Refinement Definitions in Business Manager (Merchant Tools > Search > Search Refinements), covering how to store product data in a custom attribute and expose it as a filterable refinement on the storefront.

Explanation

In the Open Commerce API (OCAPI) / Shop API, the `/search_suggestion` resource returns search suggestions (e.g., suggested products) as part of the storefront search experience. To include image data for the suggested products, the developer must explicitly request it by setting the `view_type` property for the product image, e.g.:

Why the Other Options Are Incorrect

B. If the `view_type` is not set or if the `view_type` is unknown, the image size of `small` is used by default.
– This is incorrect. OCAPI does not default to the `small` image size when `view_type` is missing or unknown. Instead, the image properties are excluded from the response. There is no automatic fallback to `small`.

C. If the `view_type` is not set or if the `view_type` is unknown, the image size of `large` is used by default.
– This is also incorrect. OCAPI does not default to the `large` image size either. As with option B, the behavior when `view_type` is missing or invalid is that the image properties are not returned — there is no default image size applied.

Reference

Salesforce B2C Commerce documentation — Open Commerce API (OCAPI) / Shop API, specifically the `/search_suggestion` resource and the `view_type` parameter for product images, which controls which image variant is returned (and whose absence/invalidity results in image properties being omitted).