Implement a Master Data Management strategy to reconcile Leads, Accounts, and Contacts.

Explanation:

The problem is about creating a single consolidated data store while allowing systems to maintain their own variations of Account/Contact names. This requires reconciliation across systems, not just replication or sync. The right solution is to implement Master Data Management (MDM), which handles cross-system identity, golden records, and reconciliation.

Correct Option

C. 🟢 Implement a Master Data Management strategy to reconcile Leads, Accounts, and Contacts
MDM ensures a consolidated store where all systems link to the same record identity. It supports different names across systems but allows UC to maintain cross-system relationships. This approach meets the need for a system-of-record split while preserving local variations and maintaining global consistency.

Incorrect Options

A. 🔴 Have Salesforce poll the OMS nightly and bring in the desired Accounts and Contacts
Polling moves data but does not solve reconciliation. Conflicts, duplicate management, and local variations would still be unresolved.

B. 🔵 Implement an integration tool to send OMS Accounts and Contacts to Salesforce
Integration tools enable data transfer, but they don’t provide a consolidated, governed store. Without MDM, UC risks inconsistencies across systems.

D. 🟡 Use the Streaming API to send Account and Contact data from Salesforce to the OMS
This only syncs Salesforce to OMS, ignoring the fact that OMS is supposed to be the system of record for Accounts/Contacts. It also doesn’t consolidate across systems.

Reference:
Salesforce Help – Master Data Management

Virtualize the remaining set of data with salesforce connect and external objects.

Explanation:

Universal Containers migrated 1 billion customer records to Heroku Postgres, needing a subset synced with Salesforce for service agents and the rest accessible on-demand. Storage limits are a concern. Salesforce Connect with External Objects offers a low-effort way to virtualize data, avoiding storage costs while enabling access. This balances real-time support needs with scalable, external data access for audits or queries.

Correct Option:

✅ A. Virtualize the remaining set of data with Salesforce Connect and external objects.
Salesforce Connect maps Heroku Postgres data to External Objects, allowing on-demand access without storing all 1 billion records in Salesforce. A subset can be synced as standard objects for service agents, while External Objects virtualize the rest, minimizing storage use. This low-effort solution leverages OData for real-time queries, meeting UC’s needs efficiently.

Incorrect Option:

❌ B. Use Heroku Connect to bi-directional, sync all data between systems.
Heroku Connect syncs entire datasets, storing all 1 billion records in Salesforce, which exceeds storage limits and increases costs. Bi-directional sync adds complexity, unneeded for on-demand access. Salesforce Connect virtualizes data, reducing storage needs while still allowing queries, making it a better fit for UC’s requirements.

❌ C. As needed, make call outs into Heroku Postgres and persist the data in Salesforce.
Callouts to Heroku Postgres with data persistence in Salesforce increase storage use, conflicting with UC’s storage concerns. Coding callouts is effort-intensive and error-prone compared to Salesforce Connect’s no-code virtualization. This approach risks performance issues and doesn’t scale well for on-demand access to large datasets.

❌ D. Migrate the data to big objects and leverage async SOQL with custom objects.
Big Objects store data in Salesforce, consuming storage and requiring data migration effort for 1 billion records. Async SOQL is query-focused, not ideal for real-time service console access. Salesforce Connect avoids storage costs by virtualizing data, offering a simpler, more efficient solution for UC’s needs.

Reference:
Salesforce Help: Salesforce Connect
Salesforce Developer: External Objects
Salesforce Developer: Big Objects

Create a duplicate rule for account, lead, and contact, use standard matching rules for these objects, and set the action to report and alert for both creates and edits.

Explanation:

Universal Containers faces duplicate Accounts, Contacts, and Leads, needing immediate prompts for potential duplicates and a report on duplicates. Salesforce’s Duplicate Management tools, like Duplicate Rules, offer a quick, no-code solution to alert users and log duplicates for reporting. The solution must be fast to implement, user-friendly, and leverage standard matching rules to address UC’s data quality issues effectively.

Correct Option:

✅ B. Create a duplicate rule for account, lead, and contact, use standard matching rules for these objects, and set the action to report and alert for both creates and edits.
Duplicate Rules with standard matching rules (e.g., exact name, email) alert users to potential duplicates during record creation or editing. Setting actions to “Alert” prompts users and “Report” logs duplicates for reporting. This no-code solution is quick to deploy, meets UC’s immediate needs, and supports reporting via the Duplicate Record Set object.

Incorrect Option:

❌ A. Create an after insert and update trigger on the account, contact and lead, and send an error if a duplicate is found using a custom matching criteria.
After triggers fire post-save, too late to prompt users during data entry. Custom matching in Apex requires coding and maintenance, delaying implementation. Duplicate Rules are faster, using standard matching, and natively support alerts and reporting, making them more suitable for UC’s urgent needs.

❌ C. Create a duplicate rule for account, lead, and contact, use standard matching rules for these objects, and set the action to block for both creates and edits.
Blocking duplicates prevents saves entirely, which may disrupt workflows if users can’t override. UC wants prompts, not blocks, and reporting. The “Block” action doesn’t log duplicates for reports as effectively as “Report and Alert,” failing to fully meet the reporting requirement.

❌ D. Create a before insert and update trigger on account, contact, and lead, and send an error if a duplicate is found using a custom matching criteria.
Before triggers can prompt users via addError(), but custom matching requires complex coding, slowing deployment. Salesforce’s Duplicate Rules with standard matching are faster to implement and maintain, offering built-in alerts and reporting without coding, aligning better with UC’s need for immediate action.

Reference:
Salesforce Developer: Apex Triggers

Use triggers to populate denormalized related fields on the Account.

Use an indexed data field with bounded data filters.

Explanation:

Universal Containers needs a report showing Accounts opened last year, grouped by industry, including Contact, Opportunity, and Order data. With millions of Accounts, performance is critical. The solution must optimize query efficiency while delivering comprehensive data. Salesforce offers tools like denormalized fields and indexed filters to ensure fast, accurate reports, avoiding performance bottlenecks caused by large datasets or complex calculations.

Correct Option:

✅ A. Use triggers to populate denormalized related fields on the Account.
Apex triggers can copy key Contact, Opportunity, or Order data (e.g., total order value) into denormalized fields on the Account. This reduces the need for complex joins in reports, improving performance with millions of records. For example, a trigger could update a custom field like Total_Opportunities__c on Account, making reports faster and simpler to build for business users.

✅ B. Use an indexed data field with bounded data filters.
Using indexed fields (e.g., Account creation date, industry) with bounded filters (e.g., “Created Date = LAST YEAR”) optimizes report performance. Salesforce indexes standard fields like Created Date and custom fields marked as External ID or Unique. Bounded filters limit the dataset, ensuring quick queries despite millions of Accounts, delivering efficient and accurate results for the business.

Incorrect Option:

❌ C. Use Formula fields to surface information in related entities on the report.
Formula fields pulling data from Contacts, Opportunities, or Orders require real-time calculations across relationships, slowing reports with millions of Accounts. Cross-object formulas are not indexed, causing performance issues. Denormalized fields or indexed filters are more efficient, as formulas increase query complexity and may hit governor limits in large datasets.

❌ D. Use unbounded date ranges to filter the report.
Unbounded date ranges (e.g., “Created Date > 2000”) scan all records, causing slow performance with millions of Accounts. Bounded ranges like “Created Date = LAST YEAR” leverage indexes, reducing query time. Unbounded filters risk timeouts and poor user experience, failing to meet the need for a high-performing report.

Reference:
Salesforce Help: Reports and Dashboards
Salesforce Developer: Apex Triggers
Salesforce Help: Indexed Fields

Patients as Person Accounts, Payment providers as Accounts, & Doctors as Contacts

Explanation:

Mapping actors to Salesforce objects requires understanding the relationships between them. In this scenario, we have distinct entities: Patients, who receive care; Doctors, who provide it; and Payment Providers, who pay for it. The goal is to choose the most appropriate standard Salesforce objects that fit the role and relationships of each actor.

Correct Option: ✅
B. Patients as Person Accounts, Payment providers as Accounts, & Doctors as Contacts

This is the optimal solution for several reasons:
✔️ Patients as Person Accounts: Patients are individuals who need care. Person Accounts are specifically designed for B2C (Business-to-Consumer) models where you are dealing directly with individuals. They combine the functionality of an Account and a Contact into a single record, which is perfect for representing a patient. 👨‍⚕️
✔️ Payment Providers as Accounts: Payment providers are organizations that pay for care. Accounts are designed to represent companies or organizations. This is the correct object to represent a business entity like an insurance company or a government agency. 🏦
✔️ Doctors as Contacts: Doctors are individuals who are associated with the care providers and work with multiple patients. Contacts are the standard object for representing individuals related to an Account. A doctor can be a Contact of a "Hospital" Account or their own "Practice" Account, and can be related to multiple Patient records through junction objects or other relationship models. 🩺

Incorrect Options: ❌

A. Patients as Contacts, Payment providers as Accounts, & Doctors as Accounts:
This is not optimal. Using Contacts for patients means they would have to be linked to an Account, which might not be a natural fit for individual patients. Mapping Doctors as Accounts is also incorrect as they are individuals, not organizations.

C. Patients as Person Accounts, Payment providers as Accounts, & Doctors as Person Account:
While this is a plausible choice for patients and payment providers, mapping doctors as Person Accounts could create issues. Doctors often work for an organization (like a hospital) and may need to be associated with that organization's Account, which is a key feature of the Contact object. Using Person Accounts for doctors removes this direct organizational linkage.

D. Patients as Accounts, Payment providers as Accounts, & Doctors as Person Accounts:
This is incorrect. Using Accounts for patients is not a standard B2C design pattern and can lead to data model inefficiencies and confusion. Accounts are for organizations, not individuals.

Reference: 📚
Salesforce Trailhead: Data Modeling
Salesforce Help: Person Accounts