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.

Explanation:

The question tests your knowledge of the four Salesforce Streaming API event types and their key constraints. The architect must guide the developer to pick the right event type by understanding publishing methods, payload customization, and security/sharing behavior of each option.

✔️ Correct Option:

C. Change Data Capture does not have record access support.
Change Data Capture events are automatically published by the platform when DML occurs on supported objects and are delivered to all subscribers regardless of organization sharing rules. This means CDC bypasses record-level security and field-level security, so downstream systems receive changes for records a user might not normally see. Architects must consider this when compliance or data segregation is required.

❌ Incorrect options:

A. Change Data Capture can be published from Apex.
Change Data Capture events are system-generated only when Salesforce records are created, updated, deleted, or undeleted. You cannot fire CDC events from Apex. Only custom Platform Events support EventBus.publish() from Apex code.

B. PushTopic Events can define a custom payload.
PushTopic events are based on a SOQL query against an sObject. The payload always contains the fields specified in that query plus standard event headers. You cannot add arbitrary fields or custom structures. For custom payloads you must use Generic Streaming or Platform Events.

🔧 Reference:
→ What is Change Data Capture? Confirms CDC gets broad access to all data regardless of sharing rules and cannot be manually fired or customized like Platform Events.
→ Platform Events vs Streaming API Events Explains PushTopic events track sObject field changes and Generic events contain arbitrary payloads, while Platform Events provide granular customization.

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

Create an Auth provider in the package and set the consumer key and consumer secret of the connected app in the central org.

Create a connected app in the central org and add the callback URL of each org the package is installed in to redirect to after successful authentication.

Use the Auth Provider configured and select the identity type as Named Principal with OAuth 2.0 as the protocol and Select Start Authentication Flow on Save.

Explanation

This scenario requires a secure and controlled OAuth integration from multiple subscriber orgs into a central Salesforce org. To ensure only a specific integration account is used, the package must rely on a centrally managed Connected App, a consistent OAuth flow, and an Auth Provider that allows a Named Principal identity type. This ensures all subscribing orgs authenticate using the same integration user authorized by the security team. Options A, C, and E align with these requirements.

✔️ Correct Options

A. Create an Auth Provider in the package and set the consumer key and consumer secret of the connected app in the central org.
This is required because all subscriber orgs need a way to authenticate into the central org. The Auth Provider inside the package uses the consumer key and secret from the central org’s connected app, allowing controlled OAuth authentication. The package does not own the connected app—only references it—which is the correct pattern for distributable integrations.

C. Create a connected app in the central org and add the callback URL of each org the package is installed in to redirect to after successful authentication.
The central org must host the connected app, because that is the OAuth authority. Since this package can be installed in multiple subscriber orgs, each installation org needs its own callback URL added to the connected app. This ensures the OAuth redirection flow works securely for every subscriber org the package is installed in.

E. Use the Auth Provider configured and select the identity type as Named Principal with OAuth 2.0 as the protocol and Select Start Authentication Flow on Save.
Choosing Named Principal ensures the same integration user is used for all incoming calls. This satisfies the security team's requirement to use a single, centrally controlled integration account. OAuth 2.0 establishes secure token-based authentication, and "Start Authentication Flow on Save" initiates the authorization process to bind the integration user.

❌ Incorrect Options

B. Contact Salesforce support and create a case to temporarily enable API access for managed packages.
There is no Salesforce setting that temporarily enables API access for managed packages. Managed packages already support API access when permitted by the subscriber org. This option does not contribute to securing the integration or setting up controlled OAuth authentication.

D. Use an encrypted field to store the password and use password management with TLS 1.2.
Password-based integrations are discouraged, insecure, and unnecessary when OAuth is available. OAuth is the recommended and secure authentication method for cross-org integrations. Storing passwords—even in encrypted fields—violates best practices and does not meet the requirement of using a centrally authorized integration account.

Reference
Connected App Use Cases
Auth Providers Overview
https://help.salesforce.com/s/articleView?id=sf.sso_authproviders.htm
Named Principal Identity Type
https://help.salesforce.com/s/articleView?id=sf.sso_authentication_named_principal.htm

Explanation:

The scenario involves Northern Trail Outfitters needing to make synchronous callouts to "available to promise" services during the customer checkout process to query product availability and reserve inventory. This must be done in a scalable way, meaning the solution should handle many users and transactions without slowing down. Let’s analyze the options:

A. The typical and worst-case historical response times
This option is correct. Synchronous callouts depend on external services responding quickly. Knowing the typical and worst-case historical response times helps the architect plan how long the checkout process might take. If response times are slow, it could delay customers, so the architect needs to ensure the system can handle these delays without failing, making this a key consideration for scalability.

C. How many concurrent service calls are being placed
This option is correct. During checkout, many customers might use the system at the same time, leading to multiple concurrent callouts to the service. The architect must ensure the integration can handle this load without crashing or slowing down. This is critical for scalability, as it determines how many users can shop and check out together.

B. The number batch jobs that can run concurrently
This option is incorrect. Batch jobs are for processing large amounts of data in the background, not for real-time synchronous callouts during checkout. Since the requirement is for immediate responses during the customer process, batch job limits don’t apply here and aren’t relevant to scalability in this context.

D. The maximum query cursors open per user on the service
This option is incorrect. Query cursors relate to how many database queries a user can have open at once in Salesforce, not the external service’s availability or response. This limit applies to internal Salesforce operations, not the synchronous callouts to the "available to promise" service, so it’s not a key factor for this integration.

Why A and C?
Considering the typical and worst-case historical response times (A) ensures the system can handle delays from the external service, keeping the checkout smooth. Evaluating how many concurrent service calls are being placed (C) ensures the solution can scale to support many customers at once. Together, these address performance and capacity, which are essential for a scalable integration.

Why not B and D?
The number of batch jobs (B) doesn’t apply to real-time callouts, which are about immediate action, not background processing. The maximum query cursors (D) is an internal Salesforce limit unrelated to the external service callouts, so it doesn’t impact this integration’s scalability.

References:
Salesforce Help: Callout Limits and Best Practices – Explains considerations for synchronous callouts and response times.
Salesforce Help: Integration Patterns and Practices – Covers scalability for concurrent callouts in integrations.
Trailhead Module: Apex Integration Services – Discusses building scalable integrations with external services.