Explanation

Experience Cloud users are considered external users, and their visibility is controlled separately from internal Salesforce users. Enabling the External Sharing Model allows the Solution Architect to define org-wide defaults specifically for external users, ensuring the indirect Sales team can access only the data they should see, while internal Sales team data remains private. This is the first step before creating more granular sharing rules or role hierarchies.

🟩 Correct Option — B ✅
🟢 The External Sharing Model provides control over data visibility for Experience Cloud users. By defining external organization-wide defaults, you can make indirect Sales records visible only to vendors while keeping internal Sales team data restricted. This ensures proper data segregation and sets the foundation for secure indirect sales processes.

🟥 Incorrect Options

A. Make internal organization-wide defaults Public Read Only ❌
🔴 Changing internal org-wide defaults to Public Read Only would expose internal data to all users, including external vendors. This violates the requirement that indirect Sales users should not see internal Sales data.

C. Start creating Sharing Sets for Experience Cloud users ❌
🔴 Sharing Sets allow you to grant access to records associated with the user’s account or contact. However, they cannot override external org-wide defaults and should be configured after external sharing defaults are established. They are a secondary step, not the first.

D. Add Indirect Sales Team to existing Direct Sales Team Role Hierarchy ❌
🔴 Placing external users in the internal role hierarchy is not recommended. Experience Cloud external users should use the external role hierarchy to prevent internal data exposure. Adding them to internal roles would risk unintended access to sensitive internal data.

📘 Summary
For Experience Cloud users representing an indirect Sales team, the first step is to enable External Sharing Model. This allows external org-wide defaults to be defined, ensuring secure segregation of internal and external data. Other options either expose internal data or are secondary steps in the sharing model configuration.

📚 Reference
Salesforce Help: Set External Sharing Model for Experience Cloud
Salesforce Trailhead: Control Access in Experience Cloud

Explanation

For a multi-cloud implementation, the core challenge is understanding how different systems (like Sales Cloud, Service Cloud, CPQ) interact to support a seamless customer experience. A user journey map is the most effective tool for this discovery, as it visualizes the complete process from the customer's perspective, ensuring no requirement from any touchpoint is missed.

🟢 Correct Option: C. Define and document the user journey map with project stakeholders to capture the customer interactions at all touchpoints.
This activity directly uncovers functional requirements by tracing the customer's path across all systems and channels. It forces stakeholders to think holistically about how data and processes must flow between clouds (e.g., from a Commerce quote to a Service case). This collaborative mapping aligns everyone on the end-to-end experience, which is the ultimate deliverable.

🔴 Incorrect Option: A. Develop and present the business case to all project stakeholders before beginning the solution design and development phase.
The business case justifies why the project should happen (e.g., ROI, strategic goals) and is typically created very early to secure funding. It is a high-level document that does not capture detailed functional or technical requirements needed for solution design and stakeholder alignment on deliverables.

🔴 Incorrect Option: B. Develop and present the project scope itemized within the requirements document to all project stakeholders before beginning the solution design and development phase.
While presenting a scoped requirements document is important, this option describes an output of the discovery process, not the activity that ensures requirements are captured. The journey mapping (option C) is the collaborative workshop technique used to create that comprehensive scope and requirements document.

🔴 Incorrect Option: D. Define and document the business value map with project stakeholders to capture the value provided by the implementation.
Similar to the business case, a value map aligns on goals and benefits (the "why"). It is crucial for prioritization but is too high-level to capture the specific system interactions, data needs, and process steps (the "what" and "how") required to design a multi-cloud solution and align on technical deliverables.

📝 Summary
The most effective method to capture comprehensive requirements for a multi-cloud project is to collaboratively map the user journey. This visual, end-to-end exercise ensures all stakeholder perspectives are included, no system interaction is overlooked, and the entire team is aligned on the customer-centric outcomes the implementation must deliver.

Reference:
This aligns with the "Discovery & Customer Success" domain of the official Salesforce B2B Solution Architect Exam Guide, which emphasizes techniques like journey mapping to understand business processes and define requirements that lead to a successful future-state architecture.

Explanation

The combination of high volume (hundreds of products) and synchronous automation/integrations (Order object) is causing governor limit failures. The most effective initial fix is leveraging asynchronous processing. This immediately grants significantly higher limits for CPU time and SOQL queries, allowing the complex logic and integration callouts to execute reliably.

Correct Option B. Review to determine if moving automation to asynchronous Apex is required. ✅
Asynchronous Apex (like Queueable or Batch Apex) is the standard solution for bulk processing and complex integrations that hit governor limits. By moving the heavy field updates and third-party callouts to the background, the original transaction gets its resources back, and the background process gains higher execution limits, resolving the current resource bottleneck efficiently.

Incorrect Options

A. Create a custom object to hold orders in queue for processing. ❌
Creating custom queuing logic is a form of over-engineering. It introduces complexity and maintenance overhead that is generally unnecessary when native asynchronous features (like Batch Apex) can solve the problem easily. This should only be considered if native tools still fail to handle extreme scale.

C. Enable Advanced Order Management to process large orders. ❌
Salesforce Order Management (OM) is a major product implementation and licensing investment. It provides a full fulfillment lifecycle solution. The Architect should always prioritize solving technical performance problems using native code patterns first before recommending such a significant, costly, and time-consuming product shift.

D. Install a third-party solution to process large orders. ❌
Introducing a third-party application brings new vendor management, integration complexity, and costs (Total Cost of Ownership, TCO). The immediate technical issue can be addressed using platform capabilities like asynchronous Apex, which avoids external dependencies and maintains a cleaner architecture.

Summary
The root cause is the synchronous execution of too much logic on a high-volume object. The best first evaluation is to implement Asynchronous Apex. This native solution offers increased governor limits needed for complex integrations and bulk updates, providing a fast, cost-effective, and architecturally sound way to solve the performance issue without new licenses or products.

Reference
Refer to the Salesforce Developer Documentation on Governor Limits and Asynchronous Apex Best Practices for handling resource-intensive bulk transactions and integrations.

Explanation

In a complex 626 multi-cloud environment with tight timeline to the steering committee, the architect must rapidly clarify the business need, map existing data reality, and assess what reporting capabilities are already licensed. These steps enable credible, cost-aware options instead of rushing into technical fixes or tool-specific designs.

Correct Answers

✅ B. Review the established and planned dataflows to understand where the systems of record sit and where data is transported to already.
Start here because every reporting decision depends on knowing the true source of each data element. Without this map you cannot decide whether to pull from Sales Cloud, push from Marketing Cloud, or replicate via MuleSoft, and you risk building on stale or duplicated data.

✅ C. Review the system landscape to identify other existing solutions for reporting and start to investigate high-level cost impacts (incl. licenses aspects) for the most viable.
Clients hate surprises on licensing. Checking current CRM Analytics, Tableau, Marketing Cloud Intelligence, or third-party BI entitlements reveals what is already paid for versus what requires new spend, giving the steering committee realistic budget numbers fast.

✅ D. Identify key drivers and high-level data scope behind the need for a consolidated reporting.
Understanding the “why” (executive dashboard, compliance, cross-cloud KPIs) and the “what” (which objects, metrics, and volume) keeps the solution focused and prevents gold-plating. It also helps prioritize the smallest useful dataset across clouds.

Incorrect Answers

❌ A. Ensure all data objects across the different clouds have a unique external identifier
This is important eventual hygiene, but it is a lengthy implementation project, not a one-week discovery activity. It belongs in the detailed design phase after the reporting platform and strategy are approved.

❌ E. Draft a solution to show how consolidated reporting can be done using CRM Analytics
Proposing CRM Analytics as the only path before understanding drivers, existing licenses, and data flows locks the conversation into one tool too early. It risks overlooking cheaper or already-owned alternatives and appears biased.

Summary
With only one week, prioritize business drivers and scope (D), map current data flows and systems of record (B), and inventory existing reporting tools with licensing costs (C). These deliver an objective, budget-ready recommendation to the steering committee. Deep technical work and single-tool proposals come after approval.

Reference
Well-Architected Framework

Explanation:

This scenario involves two key requirements:

Self-service purchasing for warehouse-type products via B2B Commerce
Sales-assisted discounting for large-volume orders via Salesforce CPQ
To meet both needs, the CPQ B2B Commerce Connector is the recommended solution.

Specifically, the Cart to Quote flow enables:

Cart sync from B2B Commerce to CPQ: Resellers build their cart in B2B Commerce.
Quote creation in CPQ: The cart is converted into a CPQ quote.
Sales rep intervention: Sales can apply discounts, adjust pricing, or configure complex products.
Sync back to Commerce: Final pricing and configuration are pushed back to the reseller’s cart.
This flow ensures a seamless experience for resellers while enabling sales reps to manage pricing approvals and volume discounts.

❌ Why the Other Options Fall Short

A. MuleSoft integration
Over-engineered for this use case. Native CPQ B2B Commerce Connector already handles cart-to-quote sync.

B. Reseller price rule
Doesn’t address the need for sales rep involvement in discount approval. Rules alone can’t handle complex negotiations.

C. Special pricing button
Creates an opportunity but lacks structured quote management, pricing logic, and cart sync. Too manual and disconnected.

📚 References
Salesforce CPQ B2B Commerce Connector Overview
Salesforce Well-Architected: B2B Commerce
Cart to Quote Flow Documentation