B2B-Solution-Architect Practice Test Questions

Explanation:

The scenario describes a complex post-merger environment with a key requirement: a "complete, real-time view of team forecasts across territories." The specific challenge is that sales users are part of multiple territories and work on multiple opportunities. This directly points to a well-documented performance consideration within Salesforce.

Option B is correct because it addresses a critical architectural limitation. When a user is assigned to a large number of territories, the forecasting engine must calculate and aggregate forecast data for that user across every single territory they are a member of. This multiplicative effect can create significant performance bottlenecks, leading to slow forecast calculation times and a poor user experience, which directly contradicts the requirement for a "real-time view." A Solution Architect must design the territory hierarchy to be as efficient as possible, avoiding unnecessarily assigning users to a high volume of territories.

Option A is incorrect because it is factually wrong. Archiving a territory model does impact the forecasts, quotas, and adjustments associated with the territories within that model. Once archived, that historical forecast data is no longer accessible in the same way, which would break the requirement for a complete view.

Option C is incorrect because, while tracking details at the opportunity line level is important for granularity in other contexts (like Salesforce CPQ), it is not the primary technical consideration for collaborative forecasting performance. The performance issue in this scenario is driven by the territory membership model and user-opportunity relationships, not the level of detail on the opportunity.

Option D is incorrect because, while true that forecast category names can be customized (via a Support case), this is a simple configuration change. It has no bearing on the architectural performance consideration required to handle the complex multi-territory assignment described in the scenario. It is a red herring.

Reference:
This is a standard performance best practice for Salesforce Forecasting, especially when using Territory Management. Salesforce documentation and implementation guides caution against assigning users to an excessive number of territories specifically due to the negative impact on forecast calculation performance.

Explanation:

🔍 B is correct because tracking Lightning usage provides measurable adoption insights. Salesforce offers the Lightning Usage App to monitor user activity, feature usage, and adoption trends—essential for post-migration success analysis.
📋 C is correct because sharing User Stories and Gap Analysis gives transparency on what functionalities were moved or modified. It helps stakeholders understand what was delivered versus what was available in Classic.
❌ A is incorrect as rolling back changes isn’t a typical best practice post-Lightning migration.
❌ D is misleading—data consistency isn’t enough to track adoption or functionality changes.

Explanation:

The "UNABLE_TO_LOCK_ROW" error is a classic Salesforce record locking issue that occurs when two or more transactions try to update the same record or its related parent records at the same time. Since Bulk API processes records in parallel batches, multiple batches can attempt to update child OrderProduct records that belong to the same parent Order record, causing lock contention. The Process Builder on the OrderProduct object also contributes to the lock by running additional logic in the same transaction.

A. Use the import wizard instead of Bulk API.
This is incorrect. The Data Import Wizard is designed for smaller data volumes (up to 50,000 records) and lacks the performance and features of the Bulk API for large-scale, enterprise-level data integrations. It would also not inherently solve the locking problem.
B. Sort the order product records by account and order before the Bulk API load.
This is a key best practice for large data loads that involve parent-child relationships. By sorting the OrderProduct records by Order (and Account, which is a parent of Order), the ETL tool can ensure that all child records belonging to the same parent are processed within the same batch. This minimizes the risk of multiple parallel batches attempting to lock the same parent Order record, significantly reducing the "UNABLE_TO_LOCK_ROW" error.
C. Change the Bulk API call to use Bulk API 2.0.
This is an ineffective solution for this specific problem. While Bulk API 2.0 simplifies the data load process by automatically managing batches, it also only uses parallel processing by default. In fact, Bulk API 1.0 has a Serial mode that could be used as an alternative, but it is less performant. Simply switching to Bulk API 2.0 does not address the underlying lock contention caused by parallel processing of child records with shared parentage.
D. Add a retry process for the records rejected by this error.
This is a standard and necessary component of any robust enterprise integration strategy. Even with optimized batching, intermittent locking errors can still occur due to other, unrelated automation or user activity. A retry mechanism, built into the ETL process, can automatically re-submit failed records, allowing them to be successfully processed after the initial lock is released.

References:
Error 'Unable to lock row - Record currently unavailable'
Implementation Best Practices on record lock issue
General Guidelines for Data Loads | Bulk API 2.0 and Bulk API ...
Salesforce Upsert – unable to obtain exclusive access to this record UNABLE_TO_LOCK_ROW - Mule 4
Enterprise resource planning - Wikipedia
Salesforce Bulk API 1 is more useful than Bulk API 2 - codeulike

Explanation:

B2B Commerce
Provides the ability to sell spare parts online in a business-to-business context.
Supports complex pricing, accounts, and product catalogs for equipment parts.
Experience Cloud
Creates the customer-facing portal where UC’s customers can log in to place orders and track status.
Salesforce Field Service
Allows customers to schedule and manage service appointments for equipment.
Optimized for dispatching technicians and managing service operations.
MuleSoft
Provides scalable, reusable API-led connectivity to the ERP system and future applications.
Ensures that orders placed in B2B Commerce are fulfilled in ERP and updates flow back to Salesforce for order status.
Future-proof for UC’s need to integrate with additional systems.

❌ Why Not the Other Options?
A. Meroku → Heroku can be used for custom applications but is not the best fit for ERP integration at enterprise scale compared to MuleSoft.
B. Sales Cloud → Sales Cloud is focused on sales automation, not order management or ERP integration. Doesn’t solve the ERP order fulfillment challenge.
C. Service Cloud + Salesforce Connect → Service Cloud is good for case management, but UC needs Field Service for scheduling appointments. Salesforce Connect provides real-time data access, but it doesn’t offer the same robust, scalable integration and orchestration that MuleSoft does.
🔍 References
Salesforce B2B Commerce Overview
Salesforce Field Service Documentation
MuleSoft API-led Connectivity
Salesforce Experience Cloud

Explanation:

The question outlines a specific requirement: translating data (Name and Description fields) on standard B2B Commerce objects (Product and Product Category) that are part of the product catalog. The key distinction here is the type of data being translated.

Why D is Correct:
B2B Commerce on Salesforce uses a feature called Data Translation specifically for translating catalog data. This includes objects like Product2 (Product), Category (Product Category), and their related fields. Enabling this feature allows administrators to create and manage translations for these specific field values directly within the B2B Commerce setup, making it the native and recommended solution for this use case.
Why A is Incorrect:
"Done data records and translate" is not a standard, recognizable feature or recommended practice within the Salesforce platform for handling translations. It is vague and does not point to a supported solution.
Why B is Incorrect:
The Translation Workbench is already enabled (as stated in the scenario: "The environment supports multiple languages via the translation workbench"). The Translation Workbench is designed for translating UI labels, picklist values, and page layouts—not for translating data records like product names and descriptions stored in standard object fields.
Why C is Incorrect:
While technically possible, creating custom fields for each translation (e.g., Description_es, Description_fr) is an anti-pattern. It creates a maintenance nightmare, does not scale with multiple languages, and is not integrated with the B2B Commerce runtime, which is built to use the Data Translation feature to serve the correct translation based on the user's language.

Reference:
The solution leverages the standard B2B Commerce Data Translation capability. This feature allows for the management of translations for catalog objects without creating custom fields or using external, unsupported methods.
Salesforce Documentation: Translate B2B Commerce Data This official documentation details the process of enabling and using Data Translation for objects like Product and Category.

Explanation:

P&C Hardware is launching an online store using Salesforce B2B Commerce, with a tight six-week timeline, and needs to analyze performance to identify bottlenecks and optimize configurations using its agile process with weekly releases. The company already uses a third-party monitoring and alerting tool deployed in the cloud for other technologies. The goal is to recommend two viable options for performance monitoring that align with the existing Salesforce stack (including MuleSoft, Sales Cloud, Service Cloud, Field Service, and Shield) and the client’s agile process.
Below is an analysis of each option:

Option A:
Leverage Shield Event Monitoring and MuleSoft to provide monitoring data to the third-party monitoring and alerting solution that's already in place at P&C Hardware.
Why it’s viable:
Salesforce Shield Event Monitoring provides real-time and historical data on user activity, performance, and security events across the Salesforce platform, including B2B Commerce. Since P&C Hardware already uses a third-party monitoring and alerting tool, integrating Shield Event Monitoring data with this tool via MuleSoft (already part of their stack) is a practical solution. MuleSoft can extract event data (e.g., API performance, page load times, or transaction errors) and feed it into the third-party tool for centralized monitoring and alerting, aligning with the client’s existing infrastructure. This approach supports the agile process by providing performance insights that can be acted upon in weekly releases.
Considerations: This requires configuring MuleSoft integrations, which may involve some development effort but leverages existing investments in MuleSoft and the third-party tool.
Reference: Salesforce Shield Event Monitoring and MuleSoft Integration with Salesforce.

Option B:
Leverage Shield Event Monitoring in conjunction with the Salesforce Debug Logs, and establish a regular review process for the Operations and Administration team.
Why it’s not ideal:
While Shield Event Monitoring is a powerful tool for tracking performance and security events, combining it with Salesforce Debug Logs is not a scalable or efficient solution for real-time performance analysis in a B2B Commerce context. Debug Logs are primarily used for troubleshooting specific user sessions or code execution (e.g., Apex or Lightning components) and are not designed for ongoing performance monitoring or identifying bottlenecks across the platform. Establishing a manual review process for Debug Logs would be time-consuming and impractical for an agile process with weekly releases, as it lacks automation and real-time insights. This option does not align well with the client’s need for proactive monitoring and optimization.
Reference: Salesforce Debug Logs.

Option C:
Leverage the B2B Commerce built-in performance monitoring dashboard to analyze performance in near real time.
Why it’s not ideal:
Salesforce B2B Commerce does not offer a robust, built-in performance monitoring dashboard specifically designed for real-time bottleneck analysis or optimization. While B2B Commerce provides some basic reporting (e.g., order or product analytics), these are focused on business metrics rather than technical performance metrics like API latency, page load times, or system bottlenecks. For detailed performance monitoring, additional tools like Shield Event Monitoring or external integrations are typically required. This option is not a strong fit for the client’s need to identify and resolve performance issues in an agile context.
Reference: B2B Commerce Reporting.

Option D:
Leverage Shield Event Monitoring in combination with the CRM Analytics Event Monitoring app as a simple out-of-the-box solution.
Why it’s viable:
The CRM Analytics Event Monitoring app (part of Salesforce’s analytics suite) is designed to work with Shield Event Monitoring to provide out-of-the-box dashboards and insights for performance, security, and usage metrics. This solution allows P&C Hardware to visualize and analyze events (e.g., API performance, page views, or transaction errors) in near real-time, which is critical for identifying bottlenecks and optimizing configurations. The app is pre-built and requires minimal setup, making it suitable for the six-week timeline and agile process. It also integrates seamlessly with the existing Salesforce stack, providing a unified approach to monitoring without relying on external tools.
Considerations: The client may need a CRM Analytics license if not already in place, but this is a scalable and efficient solution for ongoing performance analysis.
Reference: CRM Analytics Event Monitoring App.

Recommended Approach:
Option A:
Use Shield Event Monitoring to capture performance data and MuleSoft to integrate it with the existing third-party monitoring tool. This leverages P&C Hardware’s current infrastructure and ensures consistency with their monitoring strategy across technologies. It’s ideal for centralized alerting and long-term scalability.
Option D:
Implement the CRM Analytics Event Monitoring app with Shield Event Monitoring for a quick, out-of-the-box solution that provides actionable insights within Salesforce. This is particularly suitable given the six-week timeline and the need for rapid deployment.

Why Not B or C?
Option B is impractical due to the manual nature of Debug Logs and their unsuitability for real-time performance monitoring.
Option C is not viable because B2B Commerce lacks a dedicated performance monitoring dashboard for technical metrics, making it insufficient for the client’s needs.

References:
Salesforce Shield Event Monitoring: Salesforce Help
CRM Analytics Event Monitoring App: Salesforce Help
MuleSoft for Salesforce Integration: MuleSoft Documentation
Trailhead: B2B Commerce on Lightning and Salesforce Shield.

Explanation:

C. Fully document all customizations added to the system.
Documentation is crucial for long-term maintainability and support. Without it, understanding how a feature works, why it was built, or how to troubleshoot it becomes difficult, which can directly impact user efficiency and future development efforts. This ensures that new features integrate smoothly and that the system remains stable.
D. Communicate and train users on new features.
User efficiency is directly tied to their understanding and comfort with the system. Announcing new features and providing comprehensive training ensures that users know how to use the new functionality effectively. This proactive approach prevents a drop in productivity that would occur if users had to discover the features themselves or couldn't figure out how to use them.
E. Ensure development, training, and production environments are in place.
A robust environment strategy is fundamental for a healthy Salesforce org. This separation allows new features to be developed and tested in a development environment, validated and used for user training in a training (or UAT) environment, and finally deployed to the production environment. This process ensures that new features are thoroughly tested and that users are prepared to use them before they go live, minimizing disruption and maintaining efficiency.

Why the other options are incorrect:
A. Give users a way to raise support tickets for new features they do not understand.
While a support channel is necessary, relying on support tickets to teach users about new features is a reactive approach. It indicates a failure in the communication and training process (Option D). This method is inefficient and can lead to a high volume of tickets, causing a delay in resolving actual issues.
B. Give users the ability to opt-out of any new feature they dislike.
Allowing users to opt-out can create an inconsistent and fragmented user experience. It can also lead to a support nightmare as different users are on different versions of the functionality. This approach undermines the goal of a standardized, efficient solution across the organization.

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

Explanation:

A. Salesforce Connect:
This is the most appropriate solution. Salesforce Connect is a data virtualization tool that allows you to access and display data from an external source (like the ERP) in real-time, without copying or migrating the data into Salesforce. External objects are created in Salesforce to represent the external data, and service agents can view and search this data as if it were a native Salesforce object. This perfectly addresses the requirement of avoiding data duplication while providing agents with the necessary visibility. Salesforce Connect supports various protocols, including OData, which is a standard for integrating with many enterprise systems.

B. SOAP API:
While the SOAP API can be used for integration, it would require custom development (Apex, Visualforce, or Lightning Web Components) to fetch and display the data on demand. This approach does not offer the "standard capabilities" and point-and-click configuration of Salesforce Connect and would still require custom code to avoid data duplication.

C. Change Data Capture (CDC):
This is a real-time event streaming service for publishing changes to Salesforce records. CDC is designed to push changes from Salesforce to an external system, not the other way around. It would be used to keep an external system in sync with Salesforce data, not to display external data within Salesforce in real-time.

D. Bulk Rest API:
The Bulk API is optimized for loading or deleting large sets of data asynchronously, and is not designed for real-time, on-demand data access for display in the UI. Using it would require duplicating the data in Salesforce, which is explicitly against the requirement.

Explanation:

These two suggestions will help ensure that product and pricing data is synced between Salesforce CPQ, PIM, and the custom ecommerce tool and that the pricing and product structure between the custom ecommerce tool and CPQ are aligned.

This will enable a streamlined integration between the two applications and ensure that pre-negotiated contracts created in CPQ are presented accurately in the custom ecommerce tool. Using an ETL tool will automate the data synchronization process and reduce manual efforts.

✅ B. Recommend an ETl tool to synchronize all product data between Salesforce CPQ, PIM, and the custom ecommerce tool. According to 1 and 2, using an ETL tool can help you integrate Salesforce CPQ with your other systems and keep your product data consistent and updated across all channels. You can use an ETL tool to automate the data transfer between your PIM, ecommerce, and CPQ applications and avoid manual errors or delays.

✅ C. Harmonise the Pricing and Product structure of the custom ecommerce tool and CPQ to enable a streamlined integration. According to 3 and 4,Salesforce CPQ is a powerful tool that allows you to configure, price, and quote complex products and services based on various factors such as features, quantities, discounts, contracts, etc.

To integrate your custom ecommerce tool with CPQ, you need to ensure that your pricing and product structure are aligned and compatible with CPQ’s logic and rules. This will help you present the same entitlements for pre- negotiated contracts that were created in CPQ.