Explanation:

This question tests knowledge of Salesforce APIs for building custom user interfaces that align with Lightning Experience. The requirement is not just data access, but also replicating Salesforce UI behavior and metadata for a consistent look and feel in a custom mobile app.

🟢 Correct Option:

A. User Interface API
The User Interface API is specifically designed to build custom apps that mirror Salesforce Lightning Experience. It provides both data and metadata (layouts, fields, actions) in a single response, enabling developers to recreate standard UI behavior. This makes it ideal for employee-facing apps that need a native Salesforce-like experience without manually handling UI logic.

🔴 Incorrect options:

B. REST API
The REST API provides access to Salesforce data but does not include UI metadata such as layouts or field configurations. Developers would need to manually build the UI and manage logic, making it unsuitable for replicating the Lightning Experience look and feel.

C. Connect REST API
The Connect REST API is mainly used for accessing Chatter, feeds, and social collaboration features. It is not designed for building full UI-driven applications or replicating Salesforce Lightning Experience, so it does not meet the requirements.

🔧 Reference:
→ Get Started with User Interface API
Confirms it provides data and metadata to build Lightning Experience–like UIs.

→ Introduction to REST API
Explains it is primarily for data access, not UI rendering.

Explanation:

This question tests your ability to compare Platform Events and Outbound Messaging for real-time integration needs. The key evaluation factors include scalability, message delivery guarantees, fault handling, and platform-specific limits. Platform Events operate on a publish-subscribe model with event bus storage, while Outbound Messages use point-to-point SOAP push. Understanding their distinct limitations around message ordering, retry behavior, and platform quotas is critical for architecting reliable integrations .

✔️ Correct Option:

✅ Option B – This option correctly identifies that both solutions are scalable, but Platform Events have explicit Event Delivery and Publishing limits per 24-hour rolling window. Outbound Messages are governed by workflow/flow limits, not dedicated "event" limits, making this distinction architecturally important .

❌ Incorrect Options:

❌ Option A – Incorrect because both solutions use "at-least-once" delivery, meaning duplicates can occur. Neither guarantees exactly-once delivery. Outbound Messages retry with exponential backoff for up to 24 hours, but order is not guaranteed .

❌ Option C – Incorrect because message sequence is NOT guaranteed in either solution. Outbound Messages can arrive out of order, and Platform Events do not guarantee ordering under high load. Fault handling is NOT fully handled by Salesforce—consumers must implement idempotency .

🔧 Reference:
→ Platform Events Implementation Guide – Confirms event delivery limits and outbound message timeout changes.

Explanation:

The question tests the ability to design a future-state system landscape during a Salesforce CRM implementation for a B2C company. It evaluates which legacy systems can be retired while achieving a 360-degree customer view, leveraging native Salesforce capabilities for marketing/sales/service, and reusing existing enterprise quoting and order management processes.

✔️ Correct Option:

A. Email Marketing, Sales Activity, and Case Management
Salesforce provides native tools such as Marketing Cloud / Pardot for email marketing, Sales Cloud for sales activities, and Service Cloud for case management. Retiring these three systems allows the business to consolidate customer data into Salesforce for a unified 360-degree view and fully leverage its out-of-the-box marketing, sales, and service capabilities.

❌ Incorrect options:

B. Order Management, Case Management, and Email Marketing
This option is incorrect because the implementation goals explicitly require reusing the enterprise capabilities built for quoting and order management processes. Order Management must remain as the system of record and cannot be retired.

C. Sales Activity, Order Management, and Case Management
This option is incorrect because it includes Order Management, which must be retained per the reuse requirement. Retiring it would violate the goal of leveraging existing enterprise quoting and order management capabilities.

D. Sales Activity, Email Marketing, and Order Management
This option is incorrect because it proposes retiring Order Management. The business objective clearly states the need to reuse enterprise capabilities for quoting and order management, so this system must stay in the landscape.

🔧 Reference:
→ Salesforce CRM for B2C
Confirms Salesforce native strengths in marketing, sales, and service processes to consolidate customer views.

→ Salesforce Order Management
Explains how Salesforce can integrate with (rather than replace) existing order management systems when reuse is required.

Use Batch Apex

Explanation:

The requirement involves processing a very large volume of records (approximately 1 million contacts per month) based on a specific business condition (Account field status) and initiating an integration action (sending a meeting invite via an external Marketing Automation System). To prevent hitting Salesforce's strict governor limits (like CPU time, heap size, and DML rows) when processing such massive data volumes and performing asynchronous callouts, the recommended approach is to use a dedicated asynchronous processing mechanism designed for bulk operations.

Correct Option: ✅

A. Use Batch Apex
Batch Apex is the ideal solution because it is designed for processing up to 50 million records by dividing the workload into smaller, manageable batches (typically 200 records per batch). This partitioning ensures that the entire operation, which involves querying a large dataset and making a subsequent callout to the external marketing system, remains well within the governor limits. The asynchronous nature of Batch Apex allows for high-volume, reliable, and scheduled execution of the required complex logic.

Incorrect Option: ❌

B. Use Time-based workflow rule
Time-based workflow rules are not suitable for processing 1 million records monthly. Workflow rules are designed for simpler automation and are severely limited by governor constraints. Attempting to enqueue and process such a massive number of actions through this mechanism would likely lead to system performance degradation and constant failure to execute within the allowed limits for queued jobs.

C. Use Process Builder
Process Builder is an excellent declarative tool but operates within the synchronous transactional limits when an event fires. Attempting to initiate the complex logic (querying 1 million contacts, preparing data, and making a callout) from a Process Builder would cause it to immediately hit transaction limits, such as the CPU time or the total number of SOQL queries. It is not architecturally sound for bulk, scheduled, or high-volume processing.

D. Use Trigger
An Apex Trigger executes synchronously, typically on a DML event (insert, update, delete). Executing the logic for querying and integrating with an external system for 1 million contacts within a synchronous trigger context is impossible; it would instantly fail due to exceeding governor limits like the CPU time limit (10,000 milliseconds). Triggers are reserved for real-time validation or context-specific data manipulation.

Reference:
Salesforce Apex Developer Guide: Batch Apex
Apex Developer Guide

Cloud-based ETL can access Salesforce and supports queues

On-premise middleware provides APIs to legacy systems data

Explanation

To create copies of legacy data inside Salesforce, the source data must be accessible and an integration tool must be capable of loading that data into Salesforce. Since the company already uses cloud-based ETL tools and exposes APIs through on-premise middleware, the critical factors are whether the ETL tool can connect to Salesforce and whether the middleware provides API access to legacy data. Options B and C are the findings that confirm this capability.

✔️ Correct Options

B. Cloud-based ETL can access Salesforce and supports queues
A cloud ETL tool that can access Salesforce ensures the ability to extract from legacy systems (via middleware), transform, and load the data into Salesforce. Queue support improves fault tolerance and batch handling. This capability is essential for copying legacy data into Salesforce on a recurring or scheduled basis, making this a key enabling factor.

C. On-premise middleware provides APIs to legacy systems data
If the middleware already exposes APIs to legacy systems, the ETL tool can pull data from these APIs without requiring direct access to legacy databases. This is exactly what allows the ETL solution to fetch legacy data and replicate it in Salesforce. The presence of accessible APIs is fundamental to creating data copies in Salesforce.

❌ Incorrect Options

A. Only on-premise systems are allowed access to legacy systems
If only on-premise systems are allowed access, cloud ETL tools would be blocked from retrieving legacy data. This would prevent data replication into Salesforce unless major architecture changes were made. This does not support the ability to copy legacy data to Salesforce.

D. Legacy systems can use queues for on-premise integration
Queue support within legacy systems may help with internal reliability, but it does not enable data movement into Salesforce. Queue capabilities alone do not create data access or expose the data to cloud ETL tools. This does not contribute to enabling data copies inside Salesforce.

Reference
Salesforce Data Integration Patterns (ETL & API-based Integration):
https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_ptn_data_integration.htm