Configure territory management feature to support opportunity assignment.

Explanation:

The requirement describes a classic hierarchical territory model with two tiers (Zip Code -> Sales Area) and a many-to-many relationship between users and territories. This is the exact purpose of Salesforce's built-in Territory Management feature.

Option D (Correct): Territory Management is a native Salesforce feature designed for complex, hierarchical sales models. It allows you to:

✔️ Define territories based on criteria (e.g., Zip Code).
✔️ Aggregate those territories into larger areas (e.g., Sales Area).
✔️ Assign multiple users to a single territory and multiple territories to a single user.
✔️ Automatically assign opportunity ownership based on territory criteria (e.g., the Zip Code field).
✔️ Report on performance by territory and sales area effortlessly.

Option B: While assignment rules can assign records based on field values, they are not designed for a hierarchical model. Managing 1,000+ rules for each zip code and maintaining the hierarchy for reporting would be an administrative nightmare and is not scalable.

Option A & C: These are entirely manual processes. They are error-prone, not scalable, and do not automate the assignment as required. They also fail to provide the built-in hierarchical reporting structure that Territory Management offers.

Reference:
Salesforce Help: Get Started with Territory Management
Trailhead: Manage Your Sales Territory

Create an external object Invoice _x with a Lookup relationship with Opportunity.

Explanation:

This question tests the ability to choose the right integration pattern and data storage type (external vs. internal) based on volume, system of record, and reporting requirements.

✅ Why B is Correct:
The key factors are data volume and system of record.

1. Volume: With 1 million opportunities and 12 invoices each, the total invoice volume is 12 million records. While this is manageable for a custom object, it consumes significant data storage, which is a licensed cost.
2. System of Record: The ERP system is the official system for invoices ("tracks deliveries and invoicing"). The requirement is only to view invoice data in Salesforce, not to create or edit it. An External Object is perfect for this. It creates a virtual representation of the ERP data within Salesforce without storing any data itself (saving storage costs). It supports OData, which is a standard protocol for exposing data. Users can view the data in a related list on the Opportunity page as if it were a native object, fulfilling the requirement perfectly.

❌ Why A is Incorrect:
Streaming API is for near-real-time notifications, not for displaying large sets of related data in a UI. It could push a notification that an invoice status changed, but it would not create a queryable list of all 12 invoices for an opportunity that a sales rep can easily scroll through. It solves the wrong part of the problem.

❌ Why C and D are Incorrect:
Both options recommend creating a custom object (a local Salesforce table that consumes data storage). While a lookup (D) is better than a master-detail (C) in this case to avoid cascading deletions, both are suboptimal. Storing a copy of 12 million records from an external system of record leads to data redundancy, requires complex ETL processes to keep the data in sync, and unnecessarily consumes expensive Salesforce data storage. External objects are the modern, cost-effective, and architecturally sound solution for this "view-only" requirement.

🔧 Reference:
Salesforce Integration Patterns and documentation on "External Objects" and "OData Connector." The principle is to use external objects when the data is owned and mastered in an external system and only needs to be read within Salesforce.

Build a batch join to move two-year-old records off platform, and delete records from Salesforce.

Explanation:

Why archive data?
Archiving is crucial for managing data growth, maintaining platform performance, and reducing storage costs. By moving inactive or old data out of the live Salesforce org, you can free up valuable storage space and keep your Salesforce instance running efficiently.

What data should be archived?
A data archiving strategy should define what data is considered "old" or "inactive." This is often based on business rules, such as a time frame (e.g., data older than two years) or a status (e.g., closed cases, completed projects).

Where should archived data be stored?
Archived data is typically moved to an external database or a data warehouse. This can be an on-premise solution or a cloud-based service, like Amazon S3, Google Cloud Storage, or Microsoft Azure. The chosen solution should be secure, cost-effective, and provide easy access for future reporting or analysis needs.

How should data be moved?
The process of moving data from Salesforce to an external system requires a robust data integration strategy. This can be accomplished using:

➡️ ETL (Extract, Transform, Load) tools: These tools (e.g., Informatica, MuleSoft, or custom scripts) are designed to extract data from a source (Salesforce), transform it if needed, and load it into a destination (the archiving solution).
➡️ Salesforce APIs: The Bulk API is particularly useful for handling large volumes of data for both extraction and deletion.
➡️ AppExchange solutions: Many third-party solutions are available on the Salesforce AppExchange that specialize in data archiving and provide pre-built functionality for this purpose.
➡️ A well-designed archiving solution involves a clear, automated process: identify the data to be archived, extract it from Salesforce, store it securely in the external system, and then delete it from Salesforce to free up storage. The deletion step is critical and often overlooked, but without it, the primary goal of freeing up storage is not met.

🔧 For more information, you can explore the following topics in Trailhead and Salesforce documentation:
→ Large Data Volumes (LDV)
→ Data Archiving Strategies
→ Salesforce Bulk API
→ Data Migration and Integration
→ Salesforce Platform Data Architect Certification Guide

Set up a Validation Rule to prevent blank values.

Mark the field required in setup at the field level.

Explanation:

✅ A. Set up a Validation Rule to prevent blank values
A validation rule checks the data entered by the user or from an external system against a specific criteria. In this case, a rule can be configured to prevent records from being saved if the field is blank. This is a highly effective way to enforce data quality and is the most common programmatic approach.

✅ C. Mark the field required in setup at the field level
Marking a field as required in the setup at the field level is the declarative, most direct way to ensure that a field always contains a value. This setting is enforced across all entry points, including the API, which is what the external system is using. This prevents any record from being created or updated if this field is null.

Why Other Options Fail:

❌ B. Create a Workflow to default a value into this field
A workflow rule could populate a value if the field is blank, but this doesn't prevent the missing data; it just covers it up. This might be a valid workaround in some scenarios, but it doesn't solve the root problem of missing data from the source.

❌ D. Blame the customer's external system for bad data
While the external system is the source of the problem, this is not a solution that a Salesforce Architect would take. A key responsibility of a data architect is to design and implement solutions to handle data issues, not to simply point fingers.

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