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

Enabling multi-account switching requires configuring the storefront UI, user permissions, and account access. Administrators must add the switcher component, assign proper permissions, and share accounts to allow users like sales reps to purchase on behalf of multiple organizations seamlessly.

✅ Correct Options

A. Add the Switch Accounts component to the Store home page.
The Switch Accounts component provides the user interface for account switching. Adding this component to the storefront page layout makes the functionality visible and accessible. Without it on the page, users lack the interface element needed to select and switch between accounts.

B. Assign the Account Switcher User permission to the purchasing user.
The Account Switcher User permission set enables multi-account switching capability. This permission allows users to view and use the account switcher interface to toggle between accounts. Without this permission assigned, the switching feature remains inactive even with proper sharing and components configured.

C. Share the Account with the purchasing user.
Account sharing grants users access to additional buyer accounts. Using Salesforce sharing rules or manual sharing, administrators provide users visibility to specific accounts. This sharing enables users to view and select from multiple accounts when using the switcher, establishing the necessary account relationships.

❌ Incorrect Options

D. Assign the Buyer Manager permission to the purchasing user.
Buyer Manager permissions are for managing users and settings within a single organization, not switching between multiple accounts. This permission set handles internal account administration tasks like managing team members and addresses, serving a different purpose than multi-account purchasing capabilities.

E. Create an External Managed Account record.
External Managed Account records aren't required for basic account switching functionality. The core requirements focus on UI components, permissions, and sharing. While used in certain scenarios, these records add unnecessary complexity for standard account switching implementations.

📌 Summary
Enable account switching by adding the Switch Accounts component, assigning Account Switcher User permission, and sharing target accounts. These three steps provide complete multi-account purchasing functionality.

🔗 Reference
Salesforce B2B Commerce - Account Switcher Configuration

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).