Explanation:

Salesforce Connect lets Salesforce integrate external systems in real time without duplicating data. By default, it relies on OData-enabled sources, but when a source isn’t OData-enabled, architects can use the Apex Connector Framework to build a custom adapter. This adapter defines how Salesforce queries and displays data from the external system. It ensures shipment details are always up to date, accessible in Salesforce as external objects, and doesn’t require middleware.

🚫 Why not the others?

A. REST callout with Apex:
A callout only retrieves data on demand but doesn’t provide the seamless external object experience that Salesforce Connect gives. Reps wouldn’t see data in list views, reports, or related lists without custom UI.

B. Invocable web service method:
Invocable methods are meant for process automation. They can’t expose external data in real time as Salesforce records, so they don’t solve UC’s reporting and integration needs.

C. Heroku Postgres as source:
Migrating to Heroku adds cost and complexity. UC needs direct integration with the on-prem system, not another data store in the middle.

📚 Reference:
Salesforce Developer Guide: Apex Connector Framework
Salesforce Help: Salesforce Connect Overview

Explanation:

Correct Answer: C. Duplicate Contact records exist in the system
Duplicate Contact records are a common data quality issue in CRM systems. If the same customer exists more than once, Sales Reps may log calls or activities against different records, unaware they are speaking to the same person. This creates a fragmented customer history and leads to poor customer experience, as multiple reps call the same person without visibility into prior interactions. Managing duplicates through matching rules, duplicate rules, and possibly an MDM strategy is critical.

Why not the others?

A. Missing phone number on the Contact record:
A missing phone number would prevent a call from being made at all, not cause duplicate calls. While it’s a data quality issue, it does not explain why multiple reps would contact the same customer unknowingly.

B. Customer phone number has changed on the Contact record:
If a customer’s phone number changes, the risk is inability to reach them or contacting the wrong number, not multiple reps calling the same person. This is an accuracy issue, but it doesn’t fit the scenario of duplicate outreach.

D. Duplicate Activity records on a Contact:
Duplicate activities might clutter reporting but would still be tied to the same Contact record. Reps would see that another call has already been logged if they’re viewing the same record, so this wouldn’t cause unawareness of previous calls.

Reference:
Salesforce Help: Manage Duplicates
Salesforce Architect Guide: Master Data Management

Use searches against single Objects for greater speed and accuracy.

Keep searches specific and avoid wildcards where possible.

Explanation:

Why A and B are Correct?

A. Use searches against single Objects for greater speed and accuracy.
While SOSL's primary advantage is its ability to search across multiple objects, it is often more efficient to use it for searching a single, specific object when you know where the data resides. When you use RETURNING to specify only one object, the search scope is narrower, leading to faster results and more relevant data. If you are searching for a specific record type, this approach is more performant than a broad search.

B. Keep searches specific and avoid wildcards where possible.
Wildcards like * (zero or more characters) and ? (exactly one character) can be useful, but they can also significantly degrade performance. A search with a leading wildcard (e.g., *keyword) can't use the search index efficiently and may result in a full table scan, which is very slow. By keeping your search terms precise and avoiding unnecessary wildcards, you allow the SOSL search engine to use its optimized search index, resulting in faster and more accurate results.

Why C and D are Incorrect?

C. Use SOSL option to ignore custom indexes as search fields are pre-indexed.
This is incorrect. SOSL heavily relies on the search index for its performance. The fields that SOSL searches (Name, Text, Phone, and Email) are automatically indexed for this purpose. If you have custom fields that you want to be searchable, you must ensure they are properly indexed. Ignoring indexes would be a bad practice as it would force the search to perform a full scan, which is highly inefficient.

D. Use Find in “ALL FIELDS” for faster searches.
This is incorrect and is the opposite of a best practice. Using IN ALL FIELDS or a broad RETURNING clause without specifying objects will force the search to scan more data, which is slower. A more performant approach is to explicitly list the specific fields or a limited number of objects you want to search. This practice is known as "limiting the scope" of your search, and it's a key principle for improving query performance in Salesforce. For example, FIND 'keyword' IN Name FIELDS RETURNING Account is more efficient than FIND 'keyword' IN ALL FIELDS RETURNING Account.

Reference:
Salesforce documentation and best practice guides often state that while SOSL can search across many objects, you should be as specific as possible. If you know the object, you should specify it in your query to improve performance. For example, FIND 'keyword' RETURNING Account(Id, Name).

Leverage on premise data archival and build integration to view archived data.

Leverage big object to archive case data and lightning components to show archived data.

Explanation:

UC faces a storage crisis with millions of Cases. They need to retain data for 7 years for compliance but must free up storage and maintain performance. The solution must provide access to this archived data without burdening the primary Salesforce database.

Correct Options:

C. 🗄️ Leverage on-premise data archival and build integration to view archived data.
D. 🗃️ Leverage Big Objects to archive case data and Lightning components to show archived data.

Both C and D are correct. Option C involves archiving to an external system (on-premise or cloud) and building a custom integration (e.g., using APIs or a mashup) for access. Option D uses Salesforce Big Objects, a native archive solution designed for massive, rarely accessed data that can be queried via SOQL and displayed in custom Lightning components. Both effectively remove data from the primary Case table to free up storage.

Incorrect Options:

A. 📄 Export data out of Salesforce and store in flat files on an external system. While this archives data, flat files are not a suitable solution for user access. They cannot be easily queried or displayed within Salesforce for user groups, violating the access requirement. This is only a pure backup.

B. 🧱 Create a custom object to store case history and run reports on it. This does not solve the storage issue; it merely moves the data from one Salesforce object to another, continuing to consume expensive primary data storage. It is an internal relocation, not an archive.

Reference:
Salesforce Help: Big Objects
Salesforce Help: Data Archiving Considerations

Key stakeholders should review any fields that share the same purpose between systems to see how they will be used in Salesforce.

Explanation:

Option B (✔️ Best Practice) – Stakeholder alignment ensures:
1. Field-Level Ownership: Clarifies which system "owns" specific fields (e.g., "Billing Address" from System A vs. "Shipping Address" from System B).
2. Business Rules: Matches field usage to operational needs (e.g., System A’s "Customer Tier" is used for reporting, System B’s for billing).
3. MDM Integration: MDM systems enforce these rules but require human-driven decisions first.

Why Not the Others?

Option A (❌ Hands-Off Risk) – MDM systems execute rules but can’t define them without stakeholder input.
Option C (❌ Technical Overfocus) – Schema reviews are useful, but field names ≠ ownership. Business context matters more.
Option D (❌ Chaotic) – Letting the "last sync win" guarantees conflicts and data corruption.