B2C-Solution-Architect Practice Test Questions

Explanation:

✅ Summary:
This scenario focuses on connecting multiple Salesforce Clouds — B2C Commerce, Service Cloud, and Marketing Cloud — that are not natively integrated. The company needs to know which integrations must be custom-built. Not all Salesforce products have prebuilt native integrations, so a Solution Architect must identify where custom APIs and connectors are required to ensure smooth data flow across platforms.

🟢 Correct Option B:
An integration between B2C Commerce and Service Cloud must be developed. These products do not have a native connector, so customer profiles and order data must be synchronized using APIs or middleware. Without this integration, Service Cloud agents cannot see Commerce orders, and Commerce cannot leverage Service data.

🟢 Correct Option D:
An integration between B2C Commerce and Marketing Cloud is required to allow Marketing Cloud to access order, catalog, and customer data. This enables personalized campaigns and transactional messages. APIs or Commerce Cloud Einstein integrations can be used, but they are not out-of-the-box, so custom setup is needed.

🔴 Incorrect Option A:
Service Cloud and B2C Commerce are not natively integrated. Unlike Service-to-Sales Cloud integrations, Commerce requires API-based setup. Assuming they work together out of the box is incorrect, as customer, order, and product data are siloed without custom integration.

🔴 Incorrect Option C:
While Service Cloud and Marketing Cloud may require synchronization, Salesforce provides native connectors such as Marketing Cloud Connect. This reduces the need for fully custom integration. Instead of a ground-up build, the recommended approach is to use the connector with configuration.

📖 Reference:
Salesforce Help: Salesforce B2C Commerce Integrations
Salesforce Help: Marketing Cloud Connect

Explanation:

✅ Summary:
This scenario is about ensuring a single, consistent customer identity across B2C Commerce, Service Cloud, and Marketing Cloud. Since customer data exists across multiple platforms, the key challenge is aligning identity and consent. Subscriber Key in Marketing Cloud and customer profiles in Service Cloud/Commerce need alignment to provide a unified 360-degree customer view.

🟢 Correct Option A:
Sending the Marketing Cloud Subscriber Key to Service Cloud and B2C Commerce provides a consistent customer identifier across all systems. This avoids duplicate records and allows Marketing Cloud to target the right customer, while Service and Commerce can reference the same key for personalization and service.

🟢 Correct Option D:
Using Service Cloud as the system of record for customer data and consent preferences ensures governance and accuracy. Since Service Cloud is designed to store and manage customer data, it becomes the best place to centralize information and then propagate it to Marketing Cloud and Commerce for campaigns and personalization.

🔴 Incorrect Option B:
Engaging Marketing Cloud Professional Services for a subscriber key migration is unnecessary unless the subscriber key strategy is deeply flawed. In most cases, companies can use existing Subscriber Keys and extend them across other Salesforce Clouds without a complete migration.

🔴 Incorrect Option C:
Migrating Marketing Cloud data into B2C Commerce is not advisable, as Commerce is not intended to serve as the master database for customers. B2C Commerce is optimized for transactional storefront operations, not as a system of record for customer identity.

📖 Reference:
Salesforce Help: Subscriber Key Best Practices
Salesforce Help: Customer 360 Identity

Explanation:

✅ Summary:
This scenario examines the trade-offs of using a headless commerce approach. While headless enables flexibility in front-end frameworks like React and Angular, it introduces technical challenges and additional responsibilities. A Solution Architect must evaluate infrastructure needs, feature gaps, and compatibility with existing accelerators to avoid underestimating the complexity of going headless.

✅ Correct Option A:
Headless commerce may require additional infrastructure, such as Heroku or other hosting platforms, to manage custom front-end applications. Unlike SFRA, which is hosted within Commerce Cloud, headless requires external hosting and orchestration, adding operational overhead.

✅ Correct Option B:
Features built into SFRA, such as cart, checkout, or promotions, will not exist in headless implementations. Developers will need to rebuild or customize these features within the chosen front-end framework. This adds development cost and complexity.

✅ Correct Option D:
Prebuilt integrations like Service, Marketing, and LINK accelerators are designed for SFRA. They may not work seamlessly with headless setups and often require modifications or custom middleware to connect with the custom storefront. This reduces the benefits of plug-and-play accelerators.

❌ Incorrect Option C:
The Commerce SDK is used for accessing B2C Commerce APIs, but developers are not "required" to use it for security. Security is managed through OAuth and API authentication, not the SDK itself. The SDK is a convenience tool, not a mandatory requirement.

❌ Incorrect Option E:
Although developers may know React or Angular, these frameworks are not natively part of B2C Commerce. Familiarity with them does not reduce the complexity of integrating with Commerce APIs or handling commerce-specific use cases. Their web framework knowledge alone is insufficient.

📖 Reference:
Salesforce Developers: Headless Commerce Overview
Salesforce Help: Storefront Reference Architecture (SFRA)

Explanation:

An electronics company is migrating 3 million customer records from B2C Commerce to Service Cloud to enable the ‘Order on Behalf of’ feature. The Solution Architect needs an efficient method to export and import this large dataset. The solution must handle bulk data, ensure accuracy, and minimize manual effort. Using Salesforce tools for export and import ensures compatibility, scalability, and alignment with best practices for a one-time migration of customer records.

🗄️ Correct Option:

Option A: Use Business Manager to export and Data Loader to import the 3 million records into Service Cloud:
Business Manager in B2C Commerce allows exporting large datasets, like 3 million customer records, as CSV files. Salesforce Data Loader then imports these records into Service Cloud efficiently, handling bulk data with minimal errors. This method is ideal for a one-time migration, ensuring data integrity and compatibility. It’s a standard, supported approach in Salesforce, making it scalable and reliable for transferring large volumes of customer data accurately.

🗄️ Incorrect Option:

Option B: Use the Streaming API to push the 3 million customer records from B2C Commerce to Service Cloud:
The Streaming API is designed for real-time data updates, not bulk data migration. It’s unsuitable for transferring 3 million records at once, as it could overwhelm the system, cause delays, or exceed API limits. This method is better for ongoing, event-driven updates rather than a one-time batch migration, making it inefficient and impractical compared to using Business Manager and Data Loader for this scenario.

Option C: Use the Salesforce REST API to import the 3 million records into Service Cloud:
The Salesforce REST API is meant for programmatic, real-time data interactions, not bulk migrations. Importing 3 million records via REST API would be slow, resource-intensive, and prone to hitting governor limits. It requires complex custom coding, unlike the straightforward, supported approach of Data Loader. This makes it inefficient for a one-time transfer of large customer datasets from B2C Commerce to Service Cloud.

Option D: Use the Commerce Cloud REST API to import the 3 million records into Service Cloud:
The Commerce Cloud REST API is designed for accessing B2C Commerce data, not for importing data into Service Cloud. It would require custom development to extract and map 3 million records, which is complex and error-prone. This approach is less efficient than using Business Manager for export and Data Loader for import, which are built for bulk data transfers and align with Salesforce’s best practices.

🗄️ Reference:
Salesforce Help: “Data Loader Guide”
Salesforce Commerce Cloud Help: “Business Manager Data Export”

Explanation:

A company aims to integrate B2C Commerce, Service Cloud, and Order Management to support online customers with returns, exchanges, and payments. Service agents need real-time order and transaction data in Service Cloud to assist effectively. The integration should provide relevant data for customer interactions, ensuring agents can view and act on up-to-date information. The solution must be efficient, scalable, and aligned with Salesforce capabilities to enhance the customer support experience.

🤝 Correct Option:

Option C: Service agents leverage order line items, shipment, and payment information in Service Cloud:
Order line items, shipment, and payment information from B2C Commerce and Order Management can be synced to Service Cloud, enabling agents to assist with returns, exchanges, and payments. For example, agents can view a customer’s order details and process a refund directly. This capability is natively supported via integrations like Order Management, ensuring real-time, accurate data for efficient customer service, aligning with Salesforce’s focus on unified customer support.

🤝 Incorrect Option:

Option A: Service agents leverage order cancellation but only with custom development:
Order cancellation requires custom development in Service Cloud, as it’s not a native feature of the B2C Commerce-Service Cloud integration. This makes it less efficient and costlier compared to accessing order line items, shipment, and payment data, which are supported out-of-the-box. Custom solutions increase complexity and maintenance, making this option less beneficial for agents assisting with returns, exchanges, and payments in a streamlined manner.

Option B: Service agents leverage products, catalog, and inventory information directly in Service Cloud:
While product and inventory data are useful, they are less critical for returns, exchanges, and payments than order line items, shipment, and payment details. Catalog and inventory information primarily support browsing or purchasing, not post-purchase support. Service Cloud integrations focus on order-related data for customer service, making this option less relevant for the specific needs of assisting customers with their transactions.

Option D: Service agents leverage the entire case history inside of B2C Commerce:
Case history is managed in Service Cloud, not B2C Commerce, so agents wouldn’t access it in B2C Commerce. This option reverses the integration flow, as Service Cloud is the hub for case management. It doesn’t address the need for order and transaction data in Service Cloud to support returns and payments, making it irrelevant for the scenario compared to directly accessing order-related information.

🤝 Reference:
Salesforce Help: “Order Management for Service Cloud”
Salesforce Commerce Cloud Help: “B2C Commerce and Service Cloud Integration”

Explanation:

A company is migrating its legacy storefront to B2C Commerce to address performance and scalability issues. With 200,000 subscribers, 10,000 daily visitors, and 1,000 daily emails, the solution must support mobile users and replace a tightly coupled custom marketing tool. The Solution Architect should recommend a scalable, mobile-responsive storefront and a robust marketing platform to ensure seamless customer engagement, high performance, and decoupled architecture for future flexibility.

📱 Correct Option:

Option A: Build the storefront using the Storefront Reference Architecture (SFRA) and adopt Marketing Cloud for customer engagement:
SFRA is Salesforce’s modern, mobile-responsive framework for B2C Commerce, ensuring scalability and performance for 10,000 daily visitors. Marketing Cloud supports robust email campaigns for 200,000 subscribers, replacing the custom tool with advanced personalization and automation. This combination addresses mobile usage, decouples marketing from the storefront, and aligns with Salesforce best practices, providing a scalable, efficient solution for the company’s engagement and performance needs.

📱 Incorrect Option:

Option B: Build the storefront using B2C Commerce SiteGenesis architecture and adopt Pardot for customer engagement:
SiteGenesis is an older B2C Commerce framework, less optimized for mobile responsiveness and scalability compared to SFRA. Pardot is designed for B2B marketing, not B2C email campaigns for 200,000 subscribers. It lacks the robust personalization and scale needed for daily emails, making this option unsuitable for the company’s B2C-focused storefront and engagement requirements compared to SFRA and Marketing Cloud.

Option C: Modify the frontend for the existing legacy storefront to be mobile responsive. Decouple the custom-built marketing tool so it is no longer tightly tied to the storefront:
Modifying the legacy storefront doesn’t address its performance and scalability issues, which are critical for 10,000 daily visitors. Decoupling the custom marketing tool is beneficial but insufficient without a robust replacement like Marketing Cloud. Retaining the legacy system risks ongoing issues, making this less effective than migrating to B2C Commerce’s SFRA, which offers modern scalability and mobile support for the company’s needs.

Option D: Build the storefront using a headless commerce architecture and adopt Pardot for customer engagement:
Headless commerce offers flexibility but is complex and unnecessary for the company’s scale of 200,000 subscribers and 10,000 visitors. Pardot, designed for B2B marketing, doesn’t support the B2C email volume and personalization needed for 1,000 daily emails. This option is less practical than SFRA and Marketing Cloud, which provide a simpler, B2C-optimized solution for mobile responsiveness, scalability, and effective customer engagement.

📱 Reference:
Salesforce Commerce Cloud Help: “Storefront Reference Architecture (SFRA)”
Salesforce Help: “Marketing Cloud Overview”

Explanation:

(✔) Correct Option: B - Request and Reply
This pattern is designed for synchronous, real-time integrations where B2C Commerce sends a request (order details) and must wait for a specific, immediate response (order number/status) from an external system (ERP) to proceed. This ensures data consistency and allows the storefront to confirm the order was successfully received and processed by the backend system before informing the customer.

(✗) Incorrect Option: A - Asynchronous Call-Out
An asynchronous call-out sends a message (e.g., order details) without waiting for a response. The process continues immediately. This is unsuitable as the requirement explicitly states B2C Commerce must "wait for the order to be processed" and "receive a reply," which mandates a synchronous request-and-reply pattern.

(✗) Incorrect Option: C - Batch Data Synchronization
This pattern involves scheduled jobs that transfer large volumes of data (e.g., nightly product feeds). It is not real-time. Order processing requires immediate, transactional communication between systems, making batch synchronization far too slow and incapable of providing a real-time reply to the customer during checkout.

(✗) Incorrect Option: D - Publish / Subscribe
In this pattern, a system publishes an event to a message queue, and any number of subscribed systems can consume it. It is decoupled and one-way. The requirement for B2C Commerce to wait for a direct, specific reply from the ERP rules out this fire-and-forget messaging pattern.

Summary:
This scenario requires a real-time, two-way integration for order processing. B2C Commerce must submit order data to the ERP and halt its process until it receives a confirmation response. The Request and Reply pattern is the only synchronous option designed for this exact purpose, ensuring transactional integrity between the e-commerce and ERP systems.

Explanation:

(✔) Correct Option: B - Call real-time inventory services directly throughout the product grid and checkout...
This ensures the most accurate, real-time inventory count is displayed at every customer touchpoint. By checking live inventory from the source of truth (e.g., an OMS or ERP) before displaying stock levels, the risk of selling unavailable products is significantly reduced, directly mitigating overselling.

(✔) Correct Option: C - Use Order Management capabilities to support the redirection of orders...
If real-time checks fail to prevent an oversell (e.g., inventory changes between the cart and checkout pages), Order Management provides a positive customer experience. It can automatically source the order from an alternative location (another warehouse or store) to fulfill it, turning a potential stock-out into a successful sale.

(✔) Correct Option: E - Call real-time inventory services on product and cart pages to confirm that inventory has not changed.
This is a critical, secondary check. A real-time call on the cart page reconfirms inventory availability just before the customer commits to the purchase. This acts as a final safeguard against overselling that might have occurred due to high traffic and latency between the initial product page view and the checkout process.

(✗) Incorrect Option: A - Use Service Cloud to text all registered customers...
While a good post-sale customer service tool for back-in-stock notifications, this is a reactive measure, not a proactive one for mitigating overselling during a sale. It does not prevent the negative experience of a customer ordering an out-of-stock product in the first place.

(✗) Incorrect Option: D - Use both B2C Commerce and Marketing Cloud to offer email notifications...
Similar to option A, this is a valuable tool for re-engagement after an item has sold out. However, it is purely reactive and does nothing to architecturally prevent the overselling event during the high-traffic launch, which is the core requirement.

Summary:
The architecture must proactively prevent overselling and react gracefully if it occurs. Proactive measures include real-time inventory checks on key pages (B & E) to display accurate counts. The reactive measure involves using Order Management (C) to fulfill orders from alternative locations if needed, ensuring customer satisfaction even when local inventory is depleted.

Explanation:

(✔) Correct Option: D - Export the data using Business Manager, and import it into Salesforce using Data Loader.
Business Manager provides a native, no-code export function to generate CSV files of customer data. Data Loader is the robust Salesforce tool designed for handling large-volume (millions of records) data imports efficiently and reliably. This combination requires no custom development to move data from one system to the other for a one-time migration.

(✗) Incorrect Option: A - Export the data using B2C Commerce APIs, and import it into Salesforce using Data Loader.
Using APIs (like Open Commerce API) to export data requires custom script development to call the API, handle pagination, and format the data. This introduces development effort, contradicting the requirement for a solution "without additional development."

(✗) Incorrect Option: B - Export the data using B2C Commerce APIs, and import it into Salesforce using Data Import Wizard.
This option has two flaws. First, using APIs requires development, as explained in option A. Second, the Data Import Wizard is a Salesforce UI tool intended for smaller data volumes (typically < 50,000 records), not for efficiently migrating two million customer records.

(✗) Incorrect Option: C - Export the data using Business Manager, and import it into Salesforce using the Data Import Wizard.
While using Business Manager for export is correct, using the Data Import Wizard for the import is incorrect for this volume. Importing two million records via the Wizard would be extremely slow, prone to UI timeouts, and likely exceed the tool's operational limits. Data Loader is the correct tool for this task.

Summary:
For a one-time migration of two million records without custom code, the solution must use out-of-the-box tools. Business Manager's export feature provides the data extract without code. Data Loader is the official, high-volume tool for importing large datasets into Salesforce, making this the most efficient and supported approach.

Reference:
Exporting from Business Manager
Using Data Loader

Explanation:

Universal Containers (UC) wants to implement a Buy Online, Pick Up In-Store (BOPIS) functionality using their existing B2C Commerce, Marketing Cloud, and Salesforce OMS platforms. The challenge for a Solution Architect is to design a solution that addresses recent logistics issues and meets customer demand for local pickups. A key consideration is how to effectively manage and present store-specific inventory data to customers during the online shopping process, ensuring a seamless and accurate experience.

Correct Option:

The correct option is C. Manage inventory data inside of B2C Commerce so it is easier to parse by store.
For a BOPIS solution, B2C Commerce acts as the primary customer-facing platform. It is essential to manage store-level inventory data within B2C Commerce because customers need to see real-time or near-real-time stock availability for specific store locations before they can place an order. B2C Commerce's native capabilities are designed to handle this type of inventory data, making it readily available for the storefront's search and checkout processes. This approach ensures that the customer's journey, from selecting a store to confirming item availability, is smooth and efficient.

Incorrect Options:

A. Manage inventory data inside of Salesforce OMS so it is easier to parse by store.
Salesforce OMS (Order Management System) is designed to manage orders after they have been placed. While it handles order fulfillment and inventory allocation, it is not the ideal system for providing real-time inventory visibility to the customer on the storefront. Relying solely on OMS for this data would create latency and complexity, as the storefront would constantly need to query the OMS for pre-purchase inventory checks.

B. Manage B2C Commerce geolocation data for stores on an order by order basis.
Geolocation data for stores is a static or semi-static piece of information, not something that changes with each individual order. Managing it on an order-by-order basis would be inefficient and impractical. Geolocation data should be a part of the store's master data, enabling customers to find the nearest store locations easily, and should not be tied to specific transactions.

D. Marketing Cloud Mobile Push is required for this solution and must be enabled.
Marketing Cloud Mobile Push is a tool for sending notifications to customers, such as an alert that their order is ready for pickup. While it is a valuable and recommended component for enhancing the customer experience, it is an optional feature and not a fundamental requirement for the core BOPIS functionality. The core solution can function without Mobile Push, using other communication methods like email.

References:
Salesforce B2C Commerce Inventory
Salesforce Order Management