Metadata API

Explanation:

Salesforce offers multiple APIs, but each serves different purposes. Bulk and SOAP APIs are for data. Tooling API is mainly for development tooling. Metadata API is designed specifically for retrieving, deploying, creating, updating, or deleting customizations and metadata definitions — perfect for backing up org configuration.

✅ Correct Option

A. Metadata API 🛠️
Purpose-built for managing and migrating metadata. You can retrieve configurations like custom objects, fields, workflows, and page layouts programmatically, making it the right choice for automated backup solutions.

❌ Incorrect Options

B. Tooling API 🔧
Used to build custom development tools, query smaller metadata elements, or inspect Apex. It’s not designed for bulk metadata backup.

C. Bulk API in serial mode 📦
Optimized for large-scale data import/export, not metadata. Good for millions of data rows, irrelevant for backing up configuration.

D. SOAP API 🌐
General-purpose API for data CRUD operations. While versatile, it doesn’t support metadata management.

🔗 Reference:
Salesforce Help - Metadata API

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

Use Salesforce Connect and an external object to display the order history in Salesforce

Explanation:

This question describes a scenario where a massive amount of external data (50 million customers' order history) needs to be accessed by Salesforce users in a real-time or near-real-time fashion without being physically stored in the Salesforce org. The data architect must choose a solution that provides a seamless user experience while handling the large volume of data efficiently.

✔️ B. Use Salesforce Connect and an external object to display the order history in Salesforce
This is the most effective solution. Salesforce Connect is designed specifically for this use case. It allows you to create External Objects that represent data from an external system (like the ERP). When a user views a customer's record, Salesforce Connect fetches the relevant order history on-demand using a real-time callout. This avoids duplicating 50 million customer records and their order history in Salesforce, which would be inefficient and create data sync challenges. This approach provides a seamless user experience while keeping the data where it resides.

❌ A. Use an Apex callout to populate a text area field for displaying the order history.
This is not an ideal solution. An Apex callout would require a custom-coded solution, which is more complex and less scalable than Salesforce Connect. Furthermore, populating a text area field is a poor user experience. The data would be static and not easily sortable or filterable, and it could exceed field size limits.

❌ C. Import the order history into a custom Salesforce object, update nightly
Importing 50 million records and their order history would be a massive and resource-intensive undertaking. A nightly update would mean the data is always at least one day out of date, which is not ideal for a contact center that needs real-time information. This approach is prone to data latency issues and is not scalable or efficient for such a large data set.

❌ D. Embed the ERP system in an iframe and display on a custom tab.
Embedding the ERP in an iframe provides visibility but does not integrate the data into the Salesforce platform. It creates a separate, non-native user interface experience. Users would have to navigate a different system's UI within Salesforce, which is not a "seamless user experience." It also prevents any integration of the data with native Salesforce features like reporting or automation.

Reference:
Salesforce Connect

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

Leverage external data providers populate company profile and location data

Explanation:

This question tests the architect's ability to recommend scalable, automated solutions for data quality and enrichment.

✅ Why C is Correct:
Leveraging external data providers (like ZoomInfo, DiscoverOrg, or similar services) via APIs or managed packages is the most scalable and efficient solution. These services specialize in maintaining accurate and up-to-date company profiles and location data. This approach automates the process, ensures high data quality, and eliminates manual, error-prone work for sales reps. It is a best practice for data enrichment.

❌ Why A is Incorrect:
Relying on salespeople to manually search for and populate this data is inefficient, not scalable, and will result in inconsistent and incomplete data. It takes valuable time away from selling and is a poor user experience.

❌ Why B is Incorrect:
Running reports only identifies the problem; it does not solve it. It is a reactive, not a proactive, measure. Someone would still have to manually fix the records found in the report, which brings us back to the inefficiencies of option A.

❌ Why D is Incorrect:
Exporting data out of Salesforce for another team to manually update is a security risk, breaks data integrity, and is highly inefficient. It introduces latency (data is not updated in real-time) and creates a complex, error-prone process for syncing data back into Salesforce.

Reference:
The core principle here is automation and leveraging specialized tools. A Data Architect should always seek to automate data quality processes rather than rely on manual effort.