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

Explanation:

When integrating Salesforce with external systems, service availability cannot always be guaranteed. If the manufacturing system web-service goes down, the integration should gracefully handle outages without losing critical data. Here’s why option A is correct:

Middleware Queuing and Buffering:
Middleware platforms (like MuleSoft, Dell Boomi, or Informatica) can queue or buffer requests when the target system is unavailable.
Salesforce can continue sending messages to the middleware, and the middleware retries delivery once the external system is back online.
This decouples Salesforce from system downtime and ensures no data is lost.

Why not the other options?

B. Platform Event replayId and scheduled Apex:
Platform Events are great for event-driven integrations, but replaying events doesn’t solve the problem of callouts failing due to the target system being down.

C. @future and scheduled Apex retries:
This is a possible workaround for small-scale failures, but Apex retry logic is limited (governor limits, retries not guaranteed for long outages). It’s not suitable for multi-day outages.

D. Outbound Messaging retries:
Outbound Messaging only retries for a limited number of times over a short period (up to 24 hours). It won’t cover outages lasting several days.

Key takeaway:
For long-duration outages, middleware with queuing and buffering is the most reliable, scalable solution.

Reference:
Salesforce Architects Guide: Integration Patterns
Queue-Based Load Leveling Pattern: “Use a queue to decouple producers and consumers, enabling the system to handle temporary service outages without losing data.”

External gateway products in use

Explanation:

Northern Trail Outfitters wants to strengthen security and performance of outbound callouts from Salesforce to on-premise systems. When Salesforce communicates with internal servers, the integration must pass through secure network boundaries such as DMZs and firewalls.
Therefore, the most critical factor to evaluate is whether the company already uses an external integration gateway (e.g., Mulesoft, API Gateway, Reverse Proxy, VPN Tunnel, etc.), because this defines how Salesforce can securely reach the internal environment.

This directly impacts:

Secure protocol enforcement
Authentication policies
Traffic routing
Performance optimization
API management capabilities
Because of this, the primary architectural decision starts with existing network and gateway infrastructure.

✅ Correct Answer:

A. External gateway products in use

Incorrect Options

B. A Default gateway restrictions
This is too vague and not specifically relevant to Salesforce integration architecture evaluations.

C. Considerations for using Deterministic Encryption
Only relevant to encrypted data stored in Salesforce where searchability is needed — not related to outbound integration design.

D. Shield Platform Encryption Limitations
Shield protects data at rest inside Salesforce, not the secure routing and connectivity required for outbound integrations.

Named Credentials

Two way SSL

Explanation

Salesforce users need to read data from an external system via HTTPS. To ensure this integration is secure, an Integration Architect must choose security mechanisms that handle both authentication and data protection. The correct methods within Salesforce are Named Credentials and Two-Way SSL, which provide secure, scalable, and compliant integration practices.

✅ Correct Answers
✅ B. Named Credentials
Named Credentials provide a secure and centralized way to store authentication details (like usernames, passwords, OAuth tokens, or certificates) for external callouts.
They eliminate the need to hardcode credentials in Apex and automatically handle authentication for HTTPS requests.
Named Credentials also simplify endpoint management and enhance overall integration security.

Key Benefits:

Centralized credential management
Supports OAuth, JWT, Basic Auth, and custom authentication
Prevents exposure of sensitive data in code

✅ D. Two-Way SSL (Mutual Authentication)
Two-Way SSL ensures both Salesforce and the external system authenticate each other using digital certificates before data exchange occurs.
This mutual trust enhances the security of HTTPS callouts by confirming the identity of both the sender and the receiver.

Key Benefits:

Provides strong mutual authentication
Ensures encrypted and trusted communication
Ideal for highly sensitive integrations

❌ Incorrect Options
⚙️ A. Connected App
Reason:
Connected Apps are designed for inbound integrations — that is, when external systems access Salesforce using OAuth. In this scenario, Salesforce is the client making an outbound HTTPS request, so Connected App does not apply.

🚫 C. Authorization Provider
Reason:
Authorization Providers are used to define external identity providers for OAuth-based authentication into Salesforce. They are not used for securing outbound HTTPS requests from Salesforce to another system.

Reference:
Salesforce Help: Named Credentials
Salesforce Help: Configure Two-Way SSL Certificates

Summary:
To securely make outbound HTTPS requests from Salesforce:
➡ Use Named Credentials for secure credential and endpoint management.
➡ Implement Two-Way SSL for mutual authentication and encrypted communication.

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

SAML SSO and just-in-time provisioning

OpenId Connect Authentication Provider and just-in-time provisioning

Explanation:

The scenario involves a subscription-based media company implementing an Identity and Access Management (IAM) system that supports SAML and OpenID Connect to enable self-registration and Single Sign-On (SSO) for subscribers, integrating with Salesforce Community Cloud. The goal is to provide seamless access to new self-service customers. Salesforce Community Cloud (now called Experience Cloud) must support both self-registration and SSO while integrating with the IAM system. Let’s analyze the options:

A. SAML SSO and Registration Handler

This option is partially correct but not the best fit. SAML SSO is supported by Salesforce Community Cloud, allowing users to authenticate via the IAM system without re-entering credentials. However, a Registration Handler (a custom Apex class) is typically used for custom self-registration logic when users first sign up. While it can work with SAML, it’s not the most direct approach for enabling instant access for new users, as it requires custom development to map IAM attributes to Salesforce user records. Just-in-time (JIT) provisioning, which automatically creates or updates user records during SSO, is a more efficient standard approach.

B. OpenId Connect Authentication Provider and Registration Handler

This option is also partially correct but less optimal. Salesforce supports OpenID Connect as an Authentication Provider for SSO, allowing integration with the IAM system. A Registration Handler can be used for self-registration, but as with option A, it requires custom Apex to handle user creation, which is less streamlined than JIT provisioning for instant access. This makes it a less preferred choice compared to JIT provisioning with OpenID Connect.

C. SAML SSO and just-in-time provisioning

This is correct. SAML SSO enables subscribers to log in to Salesforce Community Cloud using their IAM credentials, providing a seamless SSO experience. Just-in-time (JIT) provisioning, supported with SAML, automatically creates or updates a Salesforce user record (e.g., a Community Cloud user) during the SSO process based on attributes sent by the IAM system. This ensures new self-service customers gain instant access without manual intervention or custom registration logic, aligning perfectly with the requirement for efficient self-registration and SSO.

D. OpenId Connect Authentication Provider and just-in-time provisioning

This is also correct. Salesforce supports OpenID Connect as an Authentication Provider, allowing SSO with the IAM system. Like SAML, OpenID Connect supports JIT provisioning, where user attributes from the IAM system (e.g., via ID tokens) are used to create or update Salesforce user records during login. This provides instant access for new self-service customers, meeting the requirement for self-registration and SSO in a scalable, standard way.

Why C and D?

Both SAML SSO (C) and OpenID Connect Authentication Provider (D) are supported by Salesforce Community Cloud and align with the IAM system’s capabilities (SAML and OpenID Connect). Just-in-time provisioning (in both C and D) is a standard Salesforce feature that streamlines self-registration by automatically provisioning user accounts during the SSO process, eliminating the need for custom Registration Handler logic. This is ideal for a large subscriber base requiring instant access.

Why not A and B?

While Registration Handler (in A and B) can be used for self-registration, it requires custom Apex development, which is less efficient than JIT provisioning for handling user creation/update during SSO. JIT provisioning is a declarative, out-of-the-box feature that better suits the scenario’s need for instant, scalable access.

References:

Salesforce Help: Set Up SAML for Single Sign-On – Details SAML SSO configuration and JIT provisioning in Salesforce.

Salesforce Help: OpenID Connect Authentication Providers – Explains OpenID Connect setup and JIT provisioning for SSO.

Salesforce Help: Just-in-Time Provisioning for SAML and OpenID Connect – Describes how JIT provisioning automates user creation during SSO.

Trailhead Module: Identity and Access Management – Covers SSO, self-registration, and JIT provisioning for Community Cloud.