Both Platform Events and Outbound Message offer declarative means for asynchronous near-real time needs. They aren't best suited for realtime integrations.

Number of concurrent subscribers to Platform Events is capped at 2,000. An Outbound Message configuration can pass only 100 notifications in a single messages to a SOAP end point.

Both Platform Events and Outbound Message are highly scalable. However, unlike Outbound Message, only Platform Events have Event Delivery and Event Publishing limits to be considered.

Explanation:

The customer wants to compare Platform Events vs Outbound Messages for real-time / near-real-time integration, and expects 3,000 subscribers. Key decision factors include scalability, reliability guarantees, delivery behavior, and platform limits.

Let’s evaluate each option:

✅ Correct Options

A. Both Platform Events and Outbound Message offer declarative means for asynchronous near-real time needs.
They aren't best suited for realtime integrations.
Correct: both are asynchronous, near-real-time solutions
Not recommended when strict sub-second response requirements exist
Both work well for event-driven notifications

D. Number of concurrent subscribers to Platform Events is capped at 2,000.
An Outbound Message configuration can pass only 100 notifications in a single messages to a SOAP end point.
Platform Events have enforced delivery & subscriber concurrency limits
Outbound Message batching = max 100 notifications per SOAP call
With 3,000 consumers, PE scalability limits become important

E. Both Platform Events and Outbound Message are highly scalable.
However, unlike Outbound Message, only Platform Events have Event Delivery and Event Publishing limits to be considered.
Platform Events require evaluating publish, delivery, and retention limits
OM does not have publishing limits but is limited to SOAP and endpoint reliability
PE provides more flexibility and modern architecture, but with quotas

❌ Incorrect Options

B. Incorrect — Salesforce does not guarantee once-only delivery or sequencing for either solution
Outbound Messages can be retried and may produce duplicates
Platform Events are at-least-once delivery, also possible duplicates

C. Incorrect — message ordering is not guaranteed for Outbound Messages or Platform Events
“Very high reliability” and fully Salesforce-handled fault recovery is not accurate

✅ Final Answer:
A, D, and E

Reference:
Salesforce Platform Events Limits & Considerations
Considerations for Defining and Publishing Platform Events
Outbound Messaging Limits
About SOAP API

Explanation:
The manufacturing system web service experiences multi-day outages, which means Salesforce cannot simply retry failed callouts within the platform's governor limits (retry attempts are limited in time and count). To handle extended outages without losing orders or blocking Salesforce transactions, the integration architecture must decouple the systems. Middleware with queuing and buffering capabilities provides a resilient buffer that stores outgoing messages and replays them when the target system becomes available.

Correct Option:

A. Use middleware queuing and buffering to insulate Salesforce from system outages.

This is the correct solution because:

Middleware can implement persistent queues that store order messages safely during outages.

It provides retry logic with configurable intervals and exponential backoff, which can span multiple days.

It decouples Salesforce from the manufacturing system, ensuring that Salesforce users can continue creating orders without waiting for the web service to respond.

It includes monitoring and alerting capabilities to notify administrators when the queue backs up.

This pattern is known as the "Guaranteed Delivery" or "Store and Forward" integration pattern.

Incorrect Options:

B. Use Outbound Messaging to automatically retry failed service calls.
Outbound Messaging is a legacy Salesforce feature that sends SOAP messages to an external endpoint. While it does have a retry mechanism, it is limited in scope (messages expire within 24-48 hours) and cannot handle multi-day outages. It also does not provide persistent queuing across restarts or the advanced retry logic needed for extended downtime. Additionally, it relies on SOAP, which may not be compatible with the manufacturing web service.

C. Use Platform Event replayId and custom scheduled Apex process to retrieve missed events.

While Platform Events support replay IDs to retrieve missed events, this approach has limitations for multi-day outages:

Platform Events are retained for a maximum of 72 hours (3 days), which may not cover multi-day outages.

Custom scheduled Apex would need complex logic to query and replay events, and it would still be subject to Salesforce governor limits.

This solution places the burden on Salesforce rather than leveraging dedicated middleware designed for robust error handling and persistent queuing.

Reference:
Salesforce Integration Architecture Designer Guide - "Guaranteed Delivery Pattern" recommends using middleware with persistent queues for extended outages. Salesforce Help - "Platform Events Retention" specifies the 72-hour retention window. Trailhead module "Integration Patterns" contrasts middleware-based queuing with platform-native retries, favoring middleware for multi-day outages. MuleSoft documentation describes "Store and Forward" for resilient integration.

Explanation:
The question asks what the integration architect should evaluate when integrating Salesforce with the current system landscape to support case management. Since Salesforce is being implemented for case management, it replaces the existing Case Management System. Therefore, Salesforce should integrate with the remaining systems—Order Management, Data Warehouse, and Email Management—to provide a complete 360-degree view for support agents.

Correct Option:

C. Integrate Salesforce with Data Warehouse, Order Management, and Email Management System.

This is the correct evaluation because:

Order Management System: Agents need access to order data (products, shipments, billing) to resolve cases effectively.

Data Warehouse: Historical and analytical data from the warehouse provides agents and management with insights for better decision-making.

Email Management System: Email-to-Case and two-way email sync are essential for case creation and customer communication.

Case Management System: This system is being replaced by Salesforce Service Cloud, so integrating with it would be redundant and create data silos.

Salesforce natively handles case management, making external integration unnecessary.

Incorrect Options:

A. Integrate Salesforce with Order Management System, Data Warehouse, and Case Management System.
This incorrectly includes the Case Management System as a system to integrate. Since Salesforce is being implemented for case management, the existing system should be retired. Including it violates the goal of consolidating case management into Salesforce and creates unnecessary complexity.

B. Integrate Salesforce with Email Management System, Order Management System, and Case Management System.
This option also incorrectly includes the Case Management System. Additionally, it omits the Data Warehouse, which is critical for analytics and reporting. A 360-degree customer view requires access to historical and analytical data from the warehouse, making its integration essential.

Reference:
Salesforce Integration Architecture Designer Guide - "Identify Integration Points" emphasizes that systems being replaced by Salesforce should be retired, while remaining systems (Order Management, Email, Data Warehouse) become integration points. Trailhead module "Integration Architecture Explained" reinforces the principle that Salesforce replaces redundant systems rather than integrating with them.

Named Credentials

Protected Custom Metadata Types

Explanation:

During a security review, the company discovered hard-coded secrets (usernames, passwords, OAuth tokens) in unmanaged package components. To prevent exposure of credentials in code, configuration, or metadata, Salesforce recommends secure storage mechanisms that encrypt or restrict visibility of secrets.

The solution should ensure:

No plain text credentials in org metadata
Restricted visibility to administrators only
Secure handling of authentication for outbound callouts

✅ Correct Options

B. Named Credentials
Best practice for protecting secrets used in callouts
Securely stores OAuth tokens, passwords, and authentication endpoints
Credentials are never exposed in plain text to developers or subscribers
Supports OAuth 2.0, AWS IAM, and External Credential Framework
Simplifies callouts: no need to handle tokens manually in Apex

C. Protected Custom Metadata Types
Data marked as protected is hidden from subscribers of unmanaged or managed packages
Only visible in the packaging org
Secure choice when deploying credentials via a managed package configuration
Can store configuration securely without exposing sensitive fields

❌ Incorrect Options

A. Encrypted Custom Fields
Only protects data at rest
Admins can still view decrypted values
Not intended for integration secrets or programmatic authentication

D. Protected Custom Settings
Although protected settings limit visibility to subscribers, Salesforce recommends Custom Metadata Types over Custom Settings for secure configuration in packages
Custom Settings are being deprecated for new secure configuration use cases

✅ Final Answer:

B. Named Credentials
C. Protected Custom Metadata Types

Reference:
Salesforce Security Guide – Handling Secrets in Integrations
https://developer.salesforce.com/docs
Named Credentials Overview
Named Credentials as Callout Endpoints
Protected Custom Metadata for Managed Packaging
ISVforce Guide: Build and Distribute AppExchange Solutions

Outbound Message for Salesforce to Legacy System direction and SOAP API using Enterprise WSDL for the communication back from legacy system to salesforce.

Explanation

This solution aligns perfectly with the requirements: Fire and Forget pattern and SOA API (which implies SOAP/WSDL).

Salesforce to Legacy System (Fire and Forget):

Outbound Message (OM):
OMs are a workflow action (highly declarative) that provides a fire-and-forget mechanism. Salesforce delivers a SOAP message to a specified external endpoint (the legacy application), but it does not wait for or expect a synchronous response. The legacy application receives the message and is responsible for acknowledging receipt. This satisfies the "Fire and Forget" pattern using a SOAP-based method.

Legacy System to Salesforce (Strongly Typed Response):

SOAP API using Enterprise WSDL:
To send a response back to Salesforce in a strongly typed format, the legacy system should use the Salesforce SOAP API. The Enterprise WSDL is strongly typed, meaning it is customized to the organization's specific objects and fields. This allows the legacy system to interact with specific Salesforce records (e.g., updating a status on the original record) using specific, typed data structures, which is ideal for a structured response or update.

❌ Why other options are incorrect:

B & C (Platform Events for Salesforce to Legacy System):
Platform Events are a Publish-Subscribe pattern, not the traditional SOA-based "Fire and Forget" requested, and are often consumed via the CometD stream or middleware, not directly by a legacy system expecting a WSDL/SOAP format. While PE is fire-and-forget, the Outbound Message is the SOA-compatible, SOAP-based declarative option that is a better fit for a system that "can only support SOA API."

D (SOAP API using Partner WSDL for Legacy System to Salesforce):
The Partner WSDL is loosely typed and generic; it is primarily used by complex client applications (like middleware or external applications serving multiple orgs) that need to determine data structure at runtime. The Enterprise WSDL is the appropriate choice for a single, known integration (the legacy system) that needs to work with a strongly typed, fixed schema.

🌐 Reference
Salesforce Documentation: Integration Patterns and Outbound Messaging
Outbound Messaging: Implements the Fire-and-Forget pattern using SOAP and is triggered by workflow/flow actions.
Enterprise WSDL: Strongly typed and specific to one Salesforce organization, used for integrating a single system where the schema is known in advance.