Load one Account record and one Contact record for each individual consumer.

Explanation:

This question tests knowledge of the standard Salesforce Data Model for Business-to-Consumer (B2C) scenarios.

🟢 Why C is Correct: The Salesforce platform's "Person Accounts" feature is the standard and optimal way to handle B2C data. It effectively creates a single record that represents both an Account (the business side) and a Contact (the person side). When enabled, this allows you to load data where each individual consumer is a single "Person Account" record. This leverages built-in Salesforce functionality (like standard page layouts, reports, and related lists) and is explicitly designed for this business model. It avoids the data loading complexity of trying to manage two separate objects (Account and Contact) for a single entity.

🔴 Why A is Incorrect: Creating a custom object for this purpose is an anti-pattern. It would prevent UC from using any of the standard Salesforce Sales and Service functionality built around the standard Account and Contact objects (e.g., Opportunities, Cases, Campaigns, Reports). It would essentially require rebuilding core CRM functionality from scratch.

🔴 Why B is Incorrect: Loading consumers only as Account records is not a supported model. Many standard Salesforce features, especially those related to messaging and activities (like Email, Tasks, Events), require an associated Contact. This approach would cripple the functionality of the platform.

🔴 Why D is Incorrect: This is known as the "bucket Account" model. While technically possible, it is strongly discouraged. It provides a poor user experience (all contacts are under one account, making them hard to find and report on), does not leverage the intended B2C functionality of the platform, and can lead to record ownership and sharing rule complications. Salesforce provides Person Accounts specifically to avoid this outdated practice.

🔧 Reference: Salesforce Data Model documentation, specifically the sections on "Person Accounts." The Platform Data Architect should always recommend using standard, supported features before considering custom or non-standard models.

Explanation:

Loading large volumes of data into Salesforce, especially with complex roles, territories, groups, and sharing rules, can significantly increase load times due to the system recalculating sharing rules and access permissions for each record. Let’s evaluate each option to identify the best approach to minimize load times:

✅ Option A: Enable defer sharing calculations, and suspend sharing rule calculations
This is the optimal solution. Salesforce’s sharing calculations, which determine record access based on roles, territories, groups, and sharing rules, can be computationally intensive during large data loads. By enabling the Defer Sharing Calculations feature and suspending sharing rule calculations, the data architect can temporarily disable these calculations during the data load process. Once the data is loaded, sharing calculations can be resumed, significantly reducing load times. This is a standard Salesforce best practice for large-scale data migrations.

❌ Option B: Load the data through Data Loader, and turn on parallel processing
While Salesforce Data Loader is a common tool for data imports, enabling parallel processing can lead to record-locking issues (e.g., “UNABLE_TO_LOCK_ROW” errors) when loading large volumes of data with complex sharing rules. Parallel processing does not directly address the performance impact of sharing calculations, which is the primary bottleneck in this scenario.

❌ Option C: Leverage the Bulk API and concurrent processing with multiple batches
The Bulk API is designed for large data volumes and supports batch processing, which can improve performance for data loads. However, it does not specifically address the issue of system calculations related to sharing rules. Even with the Bulk API, sharing calculations will still occur unless deferred, making this option less effective than Option A.

❌ Option D: Enable granular locking to avoid “UNABLE_TO_LOCK_ROW” error
Granular locking helps mitigate record-locking conflicts during data loads by allowing more fine-grained control over record locks. While this can reduce errors like “UNABLE_TO_LOCK_ROW,” it does not address the performance impact of sharing rule calculations, which is the primary cause of slow load times in this scenario.

🟢 Why Option A is Optimal:
Deferring and suspending sharing rule calculations directly addresses the bottleneck caused by system calculations during large data loads. This approach minimizes processing overhead, ensures timely data imports, and is explicitly recommended by Salesforce for large-scale implementations with complex sharing configurations.

🔧 References:
Salesforce Documentation: Defer Sharing Calculations
Salesforce Architect Guide: Large Data Volumes Best Practices
Salesforce Help: Data Loader Guide

Explanation:

A centralized datastore allows UC to bring customer data from all regional Salesforce orgs into one system, enabling a single source of truth and consistent reporting. This is a common pattern called multi-org consolidation. By creating a hub (such as a data warehouse, MDM system, or Customer 360), UC can aggregate Account and Contact data, resolve duplicates, and maintain consistency across branches. This design provides scalability and avoids messy point-to-point integrations.

Why not the others?

B. Use Salesforce Connect’s cross-org adapter:
While Connect can surface data from other orgs virtually, it doesn’t consolidate or normalize the data. Performance suffers when querying millions of records across orgs, and features like cross-org deduplication or unified reporting aren’t possible. It’s useful for lightweight access, but not for a true 360-degree customer view.

C. Build a bidirectional integration between all orgs:
This creates a complex web of integrations where each org pushes and pulls data to every other org. Maintenance quickly becomes unmanageable as the number of orgs grows (n² problem). Data consistency issues are also likely, since real-time sync across multiple orgs often introduces race conditions and conflicts.

D. Use an ETL tool to migrate gap Accounts and Contacts into each org:
Copying missing data into every org creates duplication instead of unification. Each org will have slightly different versions of the same record, which increases data quality problems. ETL is better suited to feed a central system, not to spread data redundantly across all orgs.

Reference:
Salesforce Architect Guide: Multi-Org Strategy

Implement an AppExchange package.

Explanation:

✅ B. Implement an AppExchange package

To track field-level changes and support data recovery, you need a comprehensive audit and backup solution.
Several AppExchange packages (like OwnBackup, Spanning, or Odaseva) offer:
1. Automated daily backups
2. Field-level change tracking
3. Restore capabilities (record-level and field-level)
4. Audit history beyond Salesforce’s native field history limitations
This is the most scalable, automated, and reliable approach for enterprises concerned about data corruption or loss.

Why Not the Others?

❌ A. Reduce data storage by purging old data
While managing storage is important, purging data does not help with recovery or auditing.
In fact, it can make things worse if critical data is removed before being backed up.

❌ C. Review projected data storage needs
Important for long-term planning, but it doesn’t provide any recovery or auditing capability.
It’s a capacity exercise, not a backup strategy.

❌ D. Schedule a weekly export file
Native Salesforce weekly data export provides only a basic backup.
It does not track field-level changes, deletions, or provide a quick restore mechanism.
Also, weekly frequency may be insufficient for detecting or responding to daily corruption.

Define a data taxonomy for product data and apply the taxonomy to the product data in the data warehouse.

Explanation:

Option C (✔️ Best Solution) – Data Taxonomy standardizes naming conventions (e.g., "Ballpoint Pen" instead of "pen") and formats (e.g., "Black" instead of "blk") at the source (data warehouse) before pushing to Salesforce.

Pros:
1. Ensures consistent product descriptions across all systems (catalog, invoices, quotes).
2. Centralized governance: Fixes inconsistencies upstream rather than in each system.
3. Scalable: Applies to future integrations.

Why Not the Others?

Option A (❌ Fragile) – Letting multiple systems update Salesforce directly without standardization perpetuates inconsistencies.
Option B (❌ Redundant) – Custom fields store variants but don’t solve the root issue (lack of standardization).
Option D (❌ Band-Aid Fix) – Triggers add technical debt and fail if data warehouse pushes incorrect values.