B2C-Solution-Architect Practice Test Questions

A.   Create a service definition in B2C Commerce that points to Marketing Cloud's REST API.

D.   After purchase, use the B2C Commerce service definition to send redemption data to Marketing Cloud.

Explanation:

Option A (✅ Correct):
To enable cross-cloud communication, B2C Commerce needs a service definition that can call Marketing Cloud’s REST API. REST is the recommended modern integration method for Marketing Cloud (SOAP is legacy and less flexible). This allows Commerce to push coupon redemption events into Marketing Cloud.

Option B (❌ Incorrect):
Marketing Cloud’s SOAP API is older and mainly used for subscriber/list management. It is not the recommended approach for orchestrating journeys or handling coupon redemption events. REST API is the standard for this type of integration.

Option C (❌ Incorrect):
Marketing Cloud should not be polling or requesting redemption details from Commerce. That would be inefficient and not event-driven. Instead, Commerce should proactively send redemption data to Marketing Cloud when the coupon is used.

Option D (✅ Correct):
After a coupon is redeemed in Commerce, the service definition should send redemption data to Marketing Cloud. This event updates the customer’s journey, ensuring reminder emails stop. This is the correct event-driven integration pattern.

🔑 Key Takeaway
For coupon redemption journey orchestration:
- Use B2C Commerce service definitions with Marketing Cloud REST API.
- Push redemption events from Commerce → Marketing Cloud to update journeys.
- Avoid SOAP API and polling approaches; use event-driven REST integration.

C.   Run a Consequence Scanning Workshop tounderstand the impact of the work

Explanation:

Universal Containers is entering a new domain involving health data (likely including sensitive metrics like heart rate, activity, sleep, or potentially Protected Health Information - PHI), which introduces significant ethical, privacy, security, and regulatory risks. Their primary concern is maintaining user trust while handling this new type of data responsibly.

Option C (Correct): Run a Consequence Scanning Workshop to understand the impact of the work.
Consequence Scanning is an agile, human-centered risk assessment practice (popularized in responsible innovation frameworks and used within Salesforce ecosystems) designed specifically to identify intended and unintended consequences of introducing new products or features—especially those involving sensitive data.
In this workshop, cross-functional teams (product, engineering, legal, security, UX) explore questions like:
- What are the privacy risks?
- How might data be misused?
- What happens if data is breached?
- How could this affect vulnerable users?
- What societal or ethical implications exist?

This directly addresses UC’s concern about trust and responsible handling of health data, helping them anticipate harms and build mitigations (e.g., data minimization, consent flows, transparency) early in the process.

Option A (Incorrect): Journey Mapping focuses on user experience and interaction flows, not on ethical or risk impacts of handling sensitive health data.

Option B (Incorrect): This is not even a valid multiple-choice option format and is irrelevant to the trust/health data concern.

Option D (Incorrect): Requirements Gathering is necessary later, but jumping straight to functional requirements skips the critical step of understanding risks and responsibilities when entering a regulated/sensitive domain.

Option E (Incorrect): While consulting a legal expert on HIPAA (not HIPPA) and PHI is important if the data qualifies as regulated health information under U.S. law, this is too narrow and reactive. Many health/wellness data scenarios fall outside HIPAA scope (e.g., consumer wellness apps), yet still carry high trust and ethical obligations. A broader risk and impact assessment (like Consequence Scanning) should come first to determine whether and how legal expertise is needed.

References:
Salesforce Trailhead and Responsible Innovation practices promote Consequence Scanning (or similar ethical impact workshops) when introducing features involving sensitive personal data.
B2C Solution Architect exam and Customer 360 guidance emphasize early risk identification for trust-sensitive features (e.g., health, financial, location data).
Consequence Scanning is a recognized agile practice for responsible technology design, especially relevant when expanding into new data domains.

Recommended Next Step: Suggest running a Consequence Scanning Workshop as the immediate next action to build shared awareness of risks and foster trust-centric design decisions.

A.   Verify that the permissions used are Login_On_Behalf, Login_Agent, and Create_Order_On_BehaIf_Of business manager functional permissions.

B.   The Order on Behalf of feature in the Service to B2C Commerce Connector only supports person accounts as a customer model by default.

E.   Verify that agents are Service Cloud and B2C Commerce users with Order on Behalf rights.

Explanation:

A. Verify that the permissions used are Login_On_Behalf, Login_Agent, and Create_Order_On_Behalf_Of business manager functional permissions.
Why it is correct: For an agent to act on behalf of a customer, the B2C Commerce Business Manager must have these specific functional permissions enabled for the agent's user role. These permissions govern the ability to initiate a session, bypass certain security checks for the agent, and finalize the transaction using the customer's context.

B. The Order on Behalf of feature in the Service to B2C Commerce Connector only supports person accounts as a customer model by default.
Why it is correct: The standard Salesforce B2C Commerce to Service Cloud Connector is architected to work with the Person Account model in Salesforce. While "Household" accounts are mentioned in the prompt, the out-of-the-box connector logic expects a 1:1 relationship between the Service Cloud record and the B2C Commerce Customer Profile, which is the standard behavior for Person Accounts. Customization is required if a non-standard model (like a shared Household account) is used.

E. Verify that agents are Service Cloud and B2C Commerce users with Order on Behalf rights.
Why it is correct: OOBO is a cross-cloud bridge. The agent must have an active identity in Service Cloud to access the "Order on Behalf" button in the console, and a corresponding B2C Commerce user account (typically mapped via the Connector) to perform the actions on the storefront. Without dual-platform access and rights, the SSO/handshake between the two systems will fail.

Detailed Analysis of Incorrect Answers
C. Default user is required for anonymous storefront shoppers.
Why it is incorrect: OOBO is designed for authenticated sessions where an agent assists a specific customer. If a shopper is anonymous, the agent should first create a customer record in Service Cloud or help the customer register. There is no architectural requirement for a "Default User" record to enable OOBO functionality; rather, it relies on the specific customer's profile.

D. The REST calls between B2C Commerce and Service Cloud do not count towards API governor limits.
Why it is incorrect: This is a dangerous misconception. All API calls made from B2C Commerce to Service Cloud (or vice versa) count toward their respective platform limits. Specifically, calls to Salesforce Service Cloud are subject to standard REST API Request Limits. A Solution Architect must ensure the volume of OOBO sessions and data syncs does not exceed the organization's daily limits.

References
Salesforce B2C Solution Kit: Order on Behalf of Solution Kit - Comprehensive guide on setting up the agent experience.
B2C Commerce Help: Functional Permissions for Order on Behalf - Lists the exact permissions required in Business Manager.
Salesforce Architects: Cross-Cloud SSO and Identity - Explains the requirement for agents to have accounts in both systems.

A.   Sync Account object using PersonContactId to access the Contact.

Explanation:

Why A is correct
With Person Accounts, Salesforce stores the person as an Account record (IsPersonAccount = true) and also creates a corresponding person Contact behind the scenes. The ID of that corresponding Contact is stored on the Person Account in the PersonContactId field.
So, if your customer data is mastered as Person Accounts and you want to map those customers correctly for Marketing Cloud usage, a reliable approach is:
- Sync Account (Person Accounts) into Marketing Cloud, and
- use PersonContactId to reference the underlying Contact when needed (for contact-centric marketing operations / identity alignment).

This aligns with the reality that marketing actions typically target a “person/contact,” even if the CRM UI shows a Person Account.

Why the other options are wrong
B. PersonSubscriberId
PersonSubscriberId is not a standard Salesforce Person Account relationship field used to access the Contact.

C. Sync Contact object using PersonAccountId
Although Person Accounts do have an underlying Contact, the key relationship field called out by Salesforce for linking the two from the Account side is PersonContactId. Also, in practice, when a business “stores customer information in Person Accounts,” syncing the Person Account (Account) object is the more direct representation of that customer record.

D. PersenSubscriberId
Not a valid standard field (and appears misspelled).

C.   Recommend Salesforce Privacy Center to manage how the Salesforce orgretains, deletes, anonymizes, and transfers customer data.

Explanation:

As of 2026, the Salesforce Privacy Center is the standard, enterprise-grade solution for managing global data privacy compliance (such as GDPR, CPRA, and CCPA) within the Salesforce ecosystem.

Automation of the "Right to be Forgotten": Privacy Center allows architects to define Right to be Forgotten (RTBF) policies. When a customer makes a request, the system can automatically delete or, more importantly, anonymize (de-identify) the record within the 30-day window required by law.

Data Masking and Anonymization: Unlike a simple delete, Privacy Center can "scramble" or "mask" specific PII (Personally Identifiable Information) fields while keeping the non-identifiable data for historical reporting, which is a common business requirement.

Scalability: For a company like UC, manual intervention (Option B) is prone to human error and failure to meet the strict 30-day legal deadline. A custom solution (Option A) requires extensive maintenance and testing every time the data model changes.

Why other options are incorrect
A. Custom Solution: While possible, it introduces significant technical debt and high maintenance costs. In 2026, Salesforce architects are encouraged to use native, managed products for legal compliance to ensure the solution is updated as privacy laws evolve.

B. Manual Review: This is not scalable and poses a high risk of non-compliance. Missing even one field (like an email address in a hidden related object) could result in heavy legal fines.

D. Soft Delete Strategy: Marking data as "archived" while still keeping the PII in the database does not satisfy the "Right to be Forgotten" legal requirement. The PII must be physically deleted or irreversibly de-identified so it can no longer be linked to the individual.

Key Domain Context (2026 Exam)
Data Models and Management (25%): This domain covers the lifecycle of data, including its secure deletion and anonymization.

Discovery and Customer Success (27%): Solution Architects must recommend tools that align with both technical feasibility and legal compliance.

Actionable Resource: For implementation details, refer to the Salesforce Privacy Center Documentation.

B.   Marketing Cloud for customer segmentation; B2C Commerce for creation of coupon codes; B2C Commerce and Marketing Cloud functionalitiesto send abandoned cart emails; Marketing Cloud to track email opens and forwards.

Explanation:

The requirements are:

- Identify VIP customers who abandoned carts (segmentation).
- Generate unique, single-use coupon codes.
- Send abandoned cart emails with the coupon.
- Track email opens and forwards.
- Disable the coupon after one use.

Evaluating each component against native Salesforce B2C capabilities:

Customer segmentation (VIP status): Marketing Cloud (via Data Extensions, filters, or Einstein STO) or Data Cloud is ideal for behavioral + attribute-based segmentation. B2C Commerce can detect abandonment but lacks advanced cross-channel segmentation for "VIP" status (typically stored in Service Cloud or Data Cloud). Marketing Cloud is the best native fit.

Coupon code creation (unique, single-use): B2C Commerce natively manages promotion rules, coupon codes (fixed or unique), and enforces single-use per customer restrictions. No native coupon engine exists in Marketing Cloud or Service Cloud for this ecommerce-specific need.

Abandoned cart emails: The Marketing Cloud Connector for B2C Commerce uses Collect.js tracking and Behavioral Triggers (Transactional Messaging API) to send abandoned cart emails from Marketing Cloud, including dynamic content like cart items and Einstein-generated recommendations. This is the standard, native abandoned cart solution.

Track email opens and forwards: Marketing Cloud provides comprehensive tracking for opens, clicks, bounces, and forwards (via the Forward to a Friend feature or tracking pixels). Service Cloud has no native email tracking for Marketing Cloud sends.

Disable after single use: Handled automatically by B2C Commerce promotion rules when the coupon is redeemed.

Why B is correct:

Marketing Cloud → segmentation + email send + tracking (opens/forwards).
B2C Commerce → coupon creation + single-use enforcement + abandonment detection.
Combined connector → abandoned cart emails.

Why others are incorrect:

A: Service Cloud is not used for segmentation or email tracking; no native coupon creation.

C: B2C Commerce lacks strong segmentation for VIP status; Service Cloud has no coupon or email tracking capabilities.

D: Service Cloud has no coupon engine; B2C Commerce does not send emails natively (relies on Marketing Cloud); Tableau CRM is for analytics, not email tracking.

References:
Salesforce Help: Marketing Cloud Connector – Behavioral Triggers for abandoned cart, Collect tracking, Einstein content.
B2C Commerce Business Manager: Promotion and coupon management with single-use restrictions.
Marketing Cloud Documentation: Built-in tracking for opens, clicks, and forwards.
B2C Solution Architect exam prep: Standard pattern for abandoned cart + personalized coupons uses B2C Commerce promotions + Marketing Cloud triggers/tracking.

A.   Configure REST Services in B2C Commerce that will be used to authenticate B2C Commerce against Marketing Cloud via its API integration and initiate a transactional email delivery.

C.   Create an API Integration in Marketing Cloud using Installed Packages that provision access to Marketing Cloud APIs by external systems like B2C Commerce.

D.   Customize the B2C Commerce storefront to trigger Marketing Cloud Transactional Messages at strategic points in the customer's experience by using Marketing Cloud's Transactional Messaging REST API. This customization should Include a payload that informs message contents.

Explanation:

A. Configure REST Services in B2C Commerce...
Why it is correct: To communicate with any external API, B2C Commerce requires a Service Definition within the Platform Service Framework. This service configuration includes the Authentication Base URI (to obtain an OAuth2 token) and the REST Messaging Base URI. This framework handles the underlying connection logic, timeout settings, and circuit breaker patterns to ensure the storefront remains performant even if the API experiences lag.

C. Create an API Integration in Marketing Cloud using Installed Packages...
Why it is correct: Marketing Cloud requires an Installed Package to provide secure, server-to-server authentication for external systems.
The architect must create a package with an API Integration component.
This generates a Client ID and Client Secret which are used by B2C Commerce to request an access token.
The package must be assigned the correct Scopes (e.g., email_send, journeys_read) to allow the storefront to trigger messages.

D. Customize the B2C Commerce storefront to trigger... using Marketing Cloud's Transactional Messaging REST API.
Why it is correct: Transactional emails are "event-driven." The storefront code must be customized (typically within the checkout or account controllers) to invoke the API at the exact moment the event occurs.
The Payload is critical: It must contain the Recipient information (email address/Subscriber Key) and the Attributes (order number, product names, total price) needed to populate the email template in real-time.

Detailed Analysis of Incorrect Answers
B. Customize the B2C Commerce storefront to invoke... This customization should first authenticate...
Why it is incorrect: While the storefront does invoke the API, the logic of "first authenticate and then deliver" should not be written as a manual sequence in the storefront's business logic. In a well-architected B2C Commerce implementation, the Service Framework (Answer A) handles authentication automatically (including token caching). Redoing this in the storefront customization is a duplication of effort and a security risk.

E. Integrate Marketing Cloud and B2C Commerce... via SFTP.
Why it is incorrect: SFTP is a batch processing tool, typically used for nightly data syncs of catalogs or customer profiles. It is not suitable for transactional emails like Order Confirmations, which customers expect to receive within seconds of a purchase. Transactional messaging must be handled via real-time APIs.

References
Salesforce Developers: Transactional Messaging API Overview – Technical documentation on the REST API used for order confirmations.
Salesforce Help: Create an API Integration in Installed Packages – Step-by-step guide for generating API credentials.
B2C Commerce Documentation: Platform Service Framework – Explains how to manage external REST service calls.

A.   B2C Commerce exports the order to Salesforce Order Management. Salesforce Order Management passes the order information to Service Cloud. Once the order is picked up by the customer, Service Cloud updates the final status in Salesforce Order Management.

Explanation:

When implementing Buy Online, Pick Up In Store (BOPIS) with B2C Commerce + Service Cloud + Salesforce Order Management (SOM):

Order Capture (B2C Commerce):
The customer places the order online in B2C Commerce.
B2C Commerce exports the order into Salesforce Order Management (SOM), which becomes the system of record for the order lifecycle.

Order Orchestration (Salesforce Order Management):
SOM manages fulfillment flows, including routing the order to the correct store for pickup.
SOM integrates with Service Cloud to provide agents visibility into the order for customer service interactions.

Order Pickup (Service Cloud):
When the customer arrives at the store, the agent confirms pickup in Service Cloud.
Service Cloud updates the order status back in Salesforce Order Management, ensuring the order lifecycle is complete and consistent across systems.

❌ Why not the other options?
B: Incorrect because B2C Commerce should not export orders directly to Service Cloud. SOM is the order lifecycle manager, not Service Cloud.

C: Incorrect because Service Cloud should not send the final status back to B2C Commerce. SOM is the system of record for order status.

D: Incorrect because duplicating order exports to both Service Cloud and SOM creates data inconsistency. SOM should be the single source of truth.

🔑 Key Takeaway
For BOPIS flows with Salesforce Order Management:
B2C Commerce → SOM → Service Cloud → SOM is the correct integration pattern.
SOM is the system of record for orders.
Service Cloud provides agent visibility and updates, but does not own the order lifecycle.

B.   Configure API integration credentials in Marketing Cloud to enable B2C Commerce to call Marketing Cloud.

C.   Implement a server-side API callout in B2C Commerce for each of the required emails.

E.   Configure a Transactional Messaging API in Marketing Cloud and use a transactional send classification for each of the required emails.

Explanation:

B. Configure API integration credentials in Marketing Cloud to enable B2C Commerce to call Marketing Cloud.
Why
To let B2C Commerce trigger transactional emails in Marketing Cloud, Commerce must be able to authenticate to Marketing Cloud APIs. That’s done by creating an API Integration (Installed Package) in Marketing Cloud and using its credentials (client id/secret, scopes) from B2C Commerce.

C. Implement a server-side API callout in B2C Commerce for each of the required emails.
Why
Transactional emails like password reset and order confirmation must be sent reliably at key events. The correct pattern is a server-side callout from B2C Commerce (e.g., in the appropriate pipelines/controllers/hooks/jobs depending on architecture) to invoke Marketing Cloud Transactional Messaging.
Server-side ensures:
- no dependency on the shopper’s browser/session
- better reliability and security for credentials
- consistent execution even if the client disconnects

E. Configure a Transactional Messaging API in Marketing Cloud and use a transactional send classification for each of the required emails.
Why
You need to set up Marketing Cloud’s Transactional Messaging (the API-driven mechanism for triggered/transactional sends) and use Transactional Send Classifications so these messages are treated correctly (sender profile, CAN-SPAM settings, transactional nature, tracking defaults, etc.).

Why not the others
A. Process Builder API event + Email Activity
This is CRM automation and doesn’t fit B2C Commerce-originated transactional events (password reset, order confirmation) in a reliable, scalable way. Also Process Builder is not the right tool for this pattern.

D. Client-side API callout
Not recommended for transactional emails because it’s less reliable and exposes integration complexity/security to the browser.

D.   Store a tokenized value for the payment card.

Explanation:

As of 2026, maintaining PCI DSS (Payment Card Industry Data Security Standard) compliance is a non-negotiable requirement for any B2C Solution Architect.

How Tokenization Works:
When a customer enters their credit card details on the B2C Commerce storefront, the data is sent directly to a Payment Gateway (e.g., Salesforce Payments, Adyen, or Stripe) without being stored on the Salesforce servers. The gateway returns a unique "token"—a non-sensitive string—that represents the credit card.

Security & Compliance:
Because the token itself has no intrinsic value and cannot be "decrypted" back into a credit card number by a hacker, it is safe to store on the Customer Profile in B2C Commerce or Service Cloud.

Business Value:
This token allows the company to facilitate one-click ordering and automatic subscription renewals by sending the token back to the gateway for future transactions, fulfilling the business requirement without the liability of handling raw financial data.

Why other options are incorrect:
A. Base64 Encoding: This is merely a data format, not a security measure. Base64 is easily reversible and provides zero security. Storing card details this way would be a major compliance violation.

B. Hashing: Hashing is a one-way process. While it can verify if a card is the same, you cannot retrieve the original number to process a payment for a subscription renewal. Therefore, it does not meet the functional requirement.

C. Raw Payment Card Details: Storing raw Primary Account Numbers (PAN) on a Salesforce profile is a critical security risk and would subject the entire organization to the most stringent (and expensive) level of PCI audit. Salesforce is not designed to be a PCI-compliant vault for raw card data.

Key Domain Context (2026 Exam):
Data Models and Management (25%): This domain tests your ability to handle sensitive PII and financial data safely.
Architecture Design (18%): Focuses on the "Service Cloud + B2C Commerce" integration for subscription models and the use of external Payment Gateways.

Actionable Resource:
For 2026 best practices, refer to the Salesforce Payments Documentation on tokenization and secure payment processing.