Data Visualization

Explanation

The core requirement is to allow users to view and update data in Salesforce that is physically stored only in an external system. This demands a real-time, virtual integration where Salesforce acts as a UI layer, but the external system remains the single source of truth. The solution must support two-way, immediate communication without replicating and storing the order data within the Salesforce database.

✅ Correct Option

A. Data Visualization
This is the correct pattern. Data Visualization involves displaying data from an external system in Salesforce UI in real-time without storing it in the Salesforce database. Tools like Salesforce Canvas or direct UI-based callouts can be used to embed the external order management application's interface directly within a Salesforce page. This allows reps to view and update orders, with all data persistence and logic handled by the remote system, fulfilling the requirement perfectly.

❌ Incorrect Options

B. Data Synchronization
This pattern involves copying and storing data in two or more systems to keep them consistent. It directly violates the key requirement that data "only persist in the external system," as it would require creating and storing Order objects in Salesforce, which would then be synchronized with the external system.

C. Process Orchestration
This pattern focuses on coordinating a long-running business process across multiple systems. While an orchestration might use the real-time visualization, the pattern itself is about managing the process flow, not the specific UI requirement for viewing and updating data without persistence.

D. Batch Processing
This pattern is for moving large volumes of data at scheduled intervals (e.g., nightly). It does not support the "real-time" requirement for sales representatives to view and update information immediately while interacting with a customer.

📚 Reference
For official guidance, refer to the Salesforce Integration Patterns & Practices documentation on the Salesforce Architect website. The "Data Visualization" pattern is specifically described as a method for displaying and interacting with external data in the Salesforce UI without storing it locally, which aligns with the requirement for the external system to be the sole system of record.

Streaming API

Explanation

The question specifies that the Integration Architect has already recommended using a Salesforce Platform Event to provide a near real-time feed. The key is to understand which API is specifically designed to consume or subscribe to these events from an external system.

Let's evaluate the options:

A. Tooling API:
This is incorrect. The Tooling API is used for building custom development tools and applications that manage Salesforce metadata. It is not designed for subscribing to real-time event feeds.

B. Streaming API:
This is correct. The Streaming API is the generic mechanism for external clients to subscribe to events. It uses the CometD protocol to maintain a long-lived connection, allowing the learning system to listen for and receive Platform Event messages the moment they are published in Salesforce. This provides the "near real-time" feed that UC requested.

C. REST API:
This is incorrect for the subscription role. The REST API can be used to publish a Platform Event from an external system to Salesforce, but it cannot be used to listen for events. An external system cannot use the REST API to get a continuous, real-time feed of events; it would have to constantly poll, which is inefficient and not real-time.

D. SOAP API:
This is incorrect for the same reason as the REST API. The SOAP API can be used to publish events to Salesforce, but it cannot act as a subscriber to receive a real-time push of events.

Key Concept

The key concept is the distinction between publishing and subscribing to Platform Events.
Publishing an Event: Sending an event message into the Salesforce Event Bus. This can be done from Apex, Process Builder, Flow, or externally via the REST API or SOAP API.
Subscribing to an Event: Listening for and receiving event messages from the Salesforce Event Bus. This is done exclusively through the Streaming API for external clients.
The learning system needs to subscribe to the Student Registration event, making the Streaming API the only correct choice.

Reference
This is a fundamental aspect of the Salesforce event-driven architecture. The official Salesforce "Streaming API" Developer Guide states that it "enables you to receive notifications for changes in Salesforce data... using a publish-subscribe model." It is the designated API for external systems to subscribe to Platform Events, PushTopics, and Generic Streaming channels to receive real-time data.

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

Invoke middleware service to retrieve valid shipping methods.

Use middleware to abstract the call to the specific shipping services.

Explanation

This scenario describes a need for dynamic integration with multiple external systems (34 different shipping services) that are frequently changing. The Integration Architect should design a solution that decouples the Salesforce application (Sales Representatives' workflow) from the complexity and volatility of the external services.

C. Use middleware to abstract the call to the specific shipping services.

Abstraction and Decoupling:
Middleware (like Mulesoft or a dedicated Enterprise Service Bus/Integration Platform) is the ideal solution to handle the complexity of 34 different services. It can act as a single, consistent interface for Salesforce. Salesforce calls one endpoint on the middleware, and the middleware handles the logic of determining the correct service, applying any necessary data transformations, and invoking that specific service's API. This isolates Salesforce from changes to the external service APIs.

B. Invoke middleware service to retrieve valid shipping methods.

Dynamic Data Retrieval:
The "valid service(s) for the customer's country" is a dynamic and frequently changing piece of information. Storing this directly in Salesforce (like in a picklist, as in option D) would require constant manual or complex automated maintenance. The best practice is for the Salesforce application to call the middleware (which is already integrating with all services and has the logic for "validity") to dynamically retrieve the current valid shipping options for a given country. This ensures the Sales Rep always sees up-to-date information.

❌ Why the Other Options are Incorrect

A. Use Platform Events to construct and publish shipper-specific events.

Use Case Mismatch:
Platform Events are an excellent solution for asynchronous, fire-and-forget, event-driven communication (e.g., notifying external systems after an Order is created). Requesting an estimate and a list of valid methods is a synchronous requirement—the Sales Rep needs the answer immediately to proceed. Middleware invoked via an outbound callout (e.g., using Apex or External Services) is the correct pattern.

D. Store shipping services in a picklist that is dependent on a country picklist.

Maintenance Nightmare:
With services "added and removed frequently," managing this through standard Salesforce configuration like dependent picklists would be highly error-prone, require constant manual updates, and likely violate the principle of having a single source of truth for dynamic, external data. The data should be retrieved dynamically from the integration layer (middleware).

📚 Reference
This solution aligns with the principles of the Integration Layer/Middleware Pattern, which is fundamental for the Integration Architect role.
Pattern: Middleware / Enterprise Service Bus (ESB)
Principle: Decoupling and Abstraction. A central layer should shield the Salesforce application from the complexity, volatility, and heterogeneity of multiple backend systems.
Source: Salesforce Integration Architecture Designer Trailmix (specifically modules covering integration patterns).

To subscribe to an event, the integration user in salesforce needs read access to
theevent entity.

To publish an event, the integration user in salesforce needs create permission on the event entity.

Error handling must be performed by the remote service because the event is effectively handed off to the remote system for further processing.

Explanation

Platform Events use an event-driven architecture characterized by asynchronous, decoupled communication. The architect must consider the operational and security requirements specific to this pattern.

D. To publish an event, the integration user in Salesforce needs create permission on the event entity.

Publishing Security:
The Salesforce user or integration mechanism (e.g., Apex, Flow, or API call) that sends the event needs the standard Create permission on the custom Platform Event object, just like creating any custom object record.

A. To subscribe to an event, the integration user in Salesforce needs read access to the event entity.

Subscribing Security:
Any subscriber (e.g., an external system connected via CometD, or an internal Apex trigger/Flow) must have Read access to the Platform Event object to receive and process the event messages.

E. Error handling must be performed by the remote service because the event is effectively handed off to the remote system for further processing.

Decoupling and Error Handling:
Platform Events are fire-and-forget. When Salesforce publishes the event, it doesn't wait for a response from the external system. Therefore, Salesforce cannot natively manage the external system's processing errors (e.g., if the external service is down or fails a business validation). The remote system is responsible for consuming the event, implementing its business logic, and handling any resulting failures (e.g., logging, retries, or sending a compensating event back to Salesforce).

❌ Why the Other Options are Incorrect

B. Salesforce needs to be able to store information about the external system in order to know which event to send out.

Event-Driven Principle:
This statement is incorrect. Platform Events promote decoupling. The publisher (Salesforce) does not and should not know or care who the subscribers are or what systems are listening. It simply publishes the event, and any interested party consumes it.

C. External system needs to have the same uptime in order to be able to keep up with Salesforce Platform Events.

Asynchronous Benefit:
This is incorrect and defeats the purpose of an asynchronous pattern. The primary advantage of Platform Events is that the external system does not need to have the same uptime. If the external system is down, the events are held in the event bus for up to 3 days (depending on the event type), and the subscriber can catch up when it comes back online. The systems are not tightly coupled by uptime requirements.

Summary:
The Integration Architect designs secure, scalable, and reliable solutions to connect Salesforce with other systems. This involves selecting the correct integration pattern (e.g., synchronous, asynchronous, bulk), the appropriate Salesforce API (e.g., REST, Bulk, UI, Platform Events), and implementing robust security models (OAuth, mTLS, DMZ) while always considering system limits and effective error handling.