Explanation

Salesforce B2B Commerce (LWR or Aura) allows for "Commerce-enabling" an existing site rather than forcing the creation of a brand-new URL. This process is handled through a specific wizard in the Commerce App. This connection is vital because a "Store" is a data container (prices, products, cart logic), while the "Site" is the visual shell. The administrative action creates the metadata link that allows the site to "talk" to the commerce engine.

✅ Correct Option

Option B:
The ‘Create a Store on Existing Site’ button is the official programmatic way to link commerce capabilities to an established Experience Cloud site. This process automates the background configuration, such as creating the store record and mapping it to the site's ID, ensuring that commerce components and objects (like Carts and Catalogs) function correctly within the existing site's framework.

❌ Incorrect Options

Option A:
While you will eventually drag and drop components, doing so before the site is commerce-enabled will not work. Without the underlying store record being linked to the site first, the components will have no data source to pull from (no products, no prices), and many commerce-specific components will not even appear in the builder menu.

Option C:
There is no "Convert" button within the Digital Experience settings that changes a standard site into a B2B Commerce site. Site types are generally defined at creation, and adding commerce functionality is managed through the Commerce App's setup tools rather than the general Salesforce Setup/Experience settings.

Option D:
While you do create a store record, there is no manual "linking" field in the Standard Setup menu that connects a store to a site. The connection must be established through the specialized Commerce Store creation wizard to ensure all related commerce metadata and internal routing are correctly synchronized.

📝 Summary
To transform an existing site into a storefront, the Administrator must navigate to the Commerce App and select "Create a Store on Existing Site." This action bridges the gap between the Experience Cloud site and the Commerce engine, allowing the site to access products, pricing, and checkout features.

🔗 Reference
Salesforce Help: Create a Store on an Existing Site

Explanation

D. ✅ List
List is a standard layout option for search results and category pages, showing products in a linear format. List layout is commonly used for product listings and search results.

E. ✅ Grid
Grid is another standard layout option, displaying products in a grid format with images and details. Grid layout is popular for showcasing products visually.

A. ❌ Matrix
Matrix layout isn't a standard option for search results and category detail pages. It's often used for reporting or data analysis. Matrix is typically used in reporting, not for page layouts.

B. ❌ Tree
Tree layout isn't typically used for search results or category pages. It's used for hierarchical data representation. Tree layout is used for showing hierarchies, not product listings.

C. ❌ Chart
Chart layout isn't a standard option for search results and category pages. Charts are used for data visualization. Charts are used for data analysis, not for product listings.

Summary:
The Administrator can use List and Grid layouts to change the appearance of search results and category detail pages. These are standard options available out-of-the-box.

Reference:
Salesforce Help: Change Page Layouts

Explanation:

To handle products with variations (like t-shirts with different sizes and colors), the standard Salesforce B2B Commerce model requires a parent-child product relationship.

✅ Create Product Variations (C):
The next crucial step is to create the individual product variations. These are the child products that represent each specific combination of size and color (e.g., "T-Shirt - Small - Blue," "T-Shirt - Medium - Red," etc.). These variations are the actual, purchasable SKUs that will be added to the cart. They are linked to the parent product.

✅ Create a T-Shirt Parent Product (D):
The first step is to create a generic "T-Shirt" parent product. This parent product serves as the container for all the different variations. It holds common information like the product description, brand, and a master price if applicable. It's the product a customer initially sees on a category page.

Why the other options are incorrect:

❌ A. Create a T-Shirt Variable Product:
"Variable Product" is not a standard term or object in Salesforce B2B Commerce for this purpose. The correct terminology is a "Parent Product" with "Product Variations" (child products).

❌ B. Create a Product Variation Rule:
While Product Variation Rules are used to define which attributes (like size and color) drive the variations, creating the rules themselves is not one of the two primary steps for implementing the products. The fundamental steps are creating the parent product and the child variations. The rules are used to manage how the variations are displayed and selected on the storefront. Without the parent and child products, the rules have nothing to act upon.

Explanation

Administrators need visibility into orders placed through B2B Commerce stores, which requires specific field-level security on the Order object. The key field linking orders to stores is "Sales Store." Setting it to Visible ensures admins can filter and view store-specific orders in lists, reports, and page layouts for effective management and oversight. ​

✅ Correct Option: D. Give Visible Field-Level Security on the Sales Store field for Orders
The Sales Store field on the Order object identifies which storefront generated the order. Making this field Visible in profiles or permission sets allows administrators to see order details tied to specific stores. Without visibility, orders appear incomplete, hindering store performance analysis and customer service.

❌ Incorrect Option: A. Give Read-Only Field-Level Security on the Store Sales field for Orders
"Store Sales" isn't the standard field name; it's "Sales Store" on Orders. Read-Only provides access but visibility is the foundational requirement first. Field names must match exactly for permissions to apply correctly in Salesforce setups. ​

❌ Incorrect Option: B. Give Read-Only Field-Level Security on the Sales Store field for Orders
While Read-Only grants access, the primary need for seeing orders is Visible permission on Sales Store field. Visibility enables the field to display on layouts and lists before read access matters. Start with Visible for basic order visibility.

❌ Incorrect Option: C. Give Visible Field-Level Security on the Store Sales field for Orders
Field name "Store Sales" doesn't exist; correct term is "Sales Store" on Order records. Incorrect naming prevents permission application. Always verify exact API/field labels in Object Manager for B2B Commerce Order configurations. ​

Summary
Visible permission on Sales Store field enables order visibility by linking them to storefronts. Read-Only comes after visibility; wrong field names block all access. Set via Profiles or Permission Sets in Setup for admin order management. ​

Reference
Salesforce Help: B2B Commerce Permission Sets
Trailhead: Configure Access and Permissions

Explanation

Authorizing a payment gateway securely in Salesforce B2B Commerce is critical to protect sensitive authentication details during callouts. The platform uses Named Credentials to handle this safely, storing credentials encrypted and managing authentication protocols automatically. This prevents exposure in code or custom fields and is the recommended method for integrating third-party gateways or custom adapters.

Correct Option:

✅ B. Create a Named Credential
Creating a Named Credential in Setup is the key step for safe authorization. It securely stores login details, API keys, OAuth tokens, or certificates for the payment gateway. This Named Credential is then associated with the PaymentGatewayProvider or Payment Gateway record, allowing Apex adapters or CommercePayments calls to authenticate securely without hardcoding sensitive information.

Incorrect Options:

❌ A. Add a username password credential to payment providers in Setup
Directly adding username/password credentials to payment provider records or custom fields is insecure and not recommended. It risks exposure and lacks features like automatic token refresh or encryption that Named Credentials provide. Salesforce directs admins to use Named Credentials for all external callout authentication in payment setups.

❌ C. Create a new payment client token
Client tokens are generated by payment processors (e.g., during card tokenization on the frontend) for secure buyer-side interactions. They are not an admin step for gateway authorization in Salesforce setup—authorization here refers to server-side gateway connectivity, handled via Named Credentials, not client tokens.

❌ D. Upload a client certificate in Setup using Certificate and Key Management
Uploading a client certificate is only required for gateways using mutual TLS authentication. Most integrations use API keys, basic auth, or OAuth, which Named Credentials support directly. Certificates are optional and not the primary or universal step for safe gateway authorization.

Summary:
The safest and standard way to authorize a payment gateway in B2B Commerce is by creating a Named Credential. This centralizes secure credential storage and integrates seamlessly with payment adapters or providers. Other options either lack security, apply to different contexts (like client-side), or are conditional rather than required steps.

Reference:
Salesforce Help - "Set Up Payment Processing" in B2B Commerce Developer Guide, and related articles on Named Credentials for payment gateway adapters (e.g., linking Named Credentials to PaymentGatewayProvider for secure callouts).