Salesforce Integration Patterns: The Architect's Catalog Explained

💬 In plain words: Integration design boils down to three core questions: Who initiates the conversation? How quickly is the answer needed (real-time vs. batch)? How reliable must the delivery be? Your answers will point you directly to one of Salesforce's official integration patterns, such as Request-Reply, Fire-and-Forget, or Batch Sync.

⚡ 1-Minute Summary

• Four key questions dictate your pattern: who starts it, how fast must it be, how much data is moving, and who owns the source of truth.
• A synchronous callout cannot run in the same transaction after you perform DML (database updates). You must use an asynchronous method like a Queueable or publish an event.
• Push architectures always beat polling. Subscribing to a single event is vastly more efficient than making 10,000 API calls asking, "Is there anything new?"

MODULE root: 'Talking to the outside & scaling'
├─ Pattern catalog (name it first!)
├─ Callouts + Named Cred + JWT (+ REST from LWC)
├─ Composite / Bulk / GraphQL API
├─ Platform Events vs CDC (intent vs change)
├─ Duplicate management / Data quality
└─ Large Data Volumes (LDV) + API limits

🔗 The Integration Patterns Catalog

📌 Example: Need a credit card authorization immediately? That's a Request-Reply callout. Sending a shipping notification to "whoever is listening"? That's a Fire-and-Forget platform event. Moving 40 million records nightly from a data warehouse? Batch Sync via the Bulk API. The ERP pushing price updates into Salesforce? Remote Call-In to your custom REST endpoint.

🧠 The Three Golden Questions: Who starts the transaction? How fast must the response be? How guaranteed must the delivery be? Your answers dictate the pattern.

To pass a Salesforce Architect interview (or design a robust system), you must use the official vocabulary. There are six primary integration patterns you need to know:

• Remote Process Invocation — Request and Reply: Salesforce initiates the call and waits for an answer. (e.g., A synchronous REST callout for a live credit check).
• Remote Process Invocation — Fire and Forget: Salesforce sends data and immediately moves on without waiting. (e.g., Publishing a Platform Event or firing an asynchronous callout).
• Batch Data Synchronization: Scheduled, high-volume ETL (Extract, Transform, Load) jobs. (e.g., Pushing nightly updates via the Bulk API 2.0).
• Remote Call-In: An external system initiates the transaction and calls into Salesforce. (e.g., Using REST, Composite, or Bulk APIs).
• UI Update Based on Data Changes: Pushing live data updates directly to a user's screen without them refreshing. (e.g., Using Change Data Capture (CDC) or Platform Events alongside lightning/empApi).
• Data Virtualization: Viewing data in Salesforce without actually storing it there. (e.g., Using Salesforce Connect and External Objects).

Pro Tip: Every time you discuss an integration solution, start by explicitly naming the pattern.

🧭 360 Card: The Integration Patterns Catalog

Rule: Four questions determine the pattern: Who starts it? How fast must it land? How big is the payload? Who owns the truth?
Gain: Naming the pattern out loud provides a shared vocabulary for the team and quickly resolves design debates.
Price: Choosing a pattern is a hard commitment. Switching from Fire-and-Forget to Request-Reply mid-project requires a massive rebuild on both sides.
Limits: The direction of the flow dictates the toolset. Inbound flows rely on REST, Composite, or Bulk APIs. Outbound flows rely on Callouts, Webhooks, or Events.
Trap: Inventing a custom "hybrid" pattern. While it might fit your specific use case, new developers won't recognize it, and Salesforce documentation won't support it. Stick to the standard six.

💡 Core Q&A: Real-World Scenarios

Q: For each pattern, give the one-line selection criterion and the primary Salesforce mechanism.

🎯 Say this first: "I select the pattern based on whether we need the answer now, if we are just telling another system and moving on, if it's volume on a schedule, or if they are calling us."

A: Here is how to match the criterion to the pattern:

• Process must wait for an answer? Request-Reply. Use a synchronous Apex callout, ensuring you have a timeout and degradation plan.
• Salesforce initiates, but the outcome can be eventually consistent? Fire-and-Forget. Publish a Platform Event consumed by middleware, or use an async callout.
• Large volumes on a schedule with no real-time requirement? Batch Data Sync. Use the Bulk API 2.0 driven by an ETL tool during off-peak hours.
• External system owns the trigger moment? Remote Call-In. They use REST or Composite APIs for transactional updates, or Bulk for volume.
• Users must see changes instantly on-screen? UI Update. Use CDC or Platform Events combined with empApi.
• Data must remain in the external system for compliance or volume reasons? Data Virtualization. Use Salesforce Connect to expose External Objects.

Q: Middleware or Point-to-Point — how do you decide, honestly rather than dogmatically?

A: A point-to-point integration is perfectly acceptable for one or two simple, stable connections. In those cases, middleware just adds unnecessary cost and a potential point of failure. However, middleware (like an ESB or iPaaS like MuleSoft) is mandatory in four scenarios:

• The N-Squared Problem: When three or more systems need to share the same data, point-to-point creates a messy web of connections.
• Complex Logic: If data transformation and orchestration logic are too heavy and risk hitting Salesforce Governor Limits.
• Durability Needs: When you require guaranteed delivery, retry logic, and queueing that exceeds the standard retention window of Platform Events.
• Centralized Monitoring: When the enterprise requires a single pane of glass ("one throat to choke") to monitor all API traffic.

⚠ Trap: Never answer "always use middleware." A senior architect evaluates the cost, complexity, and tipping point before recommending an iPaaS.

Q: Sketch this integration architecture: Orders created in Salesforce must reach an ERP within a minute. ERP inventory updates must show in Salesforce immediately. And 2 million historical orders must be migrated once.

A: You are dealing with three distinct patterns here:

• Order-to-ERP (Fire-and-Forget): Publish an Order Platform Event upon record commit. Middleware subscribes to the event and delivers it to the ERP with retry logic. Using a synchronous callout here is dangerous because it tightly couples the Salesforce save process to the ERP's uptime.
• Inventory-to-Salesforce (Remote Call-In): The ERP (or middleware) pushes updates into Salesforce using the REST API, performing an upsert based on an External ID.
• Historical Load (Batch Data Sync): A one-off data migration utilizing the Bulk API 2.0, sequenced logically (parents before children) to avoid locking errors.

Across all three patterns, ensure you use retry-safe External IDs, build a reconciliation report, and monitor event delivery lag.

Q: Inbound vs. Outbound integration — what is the difference, and what tools serve each?

A: Direction is all about who initiates the call:

• INBOUND (They call us): The external system initiates. We provide standard REST/SOAP APIs, Composite APIs, or Bulk API 2.0. If the payload is highly specific, we build custom Apex REST endpoints (@RestResource). Authentication relies on Connected Apps or External Client Apps assigned to a dedicated Integration User profile.
• OUTBOUND (We call them): Salesforce initiates. We use Apex Callouts or declarative External Services. Authentication is managed securely via Named Credentials.
• Events (The Middle Ground): Salesforce publishes a message, and the external system subscribes and pulls it down asynchronously.

When designing a full integration, you usually need both directions. Treat them as separate flows in your documentation, as each has its own limits, auth methods, and failure scenarios.

Q: Real-time vs. Batch — how do you make the call, and how do you ensure retries are safe?

🎯 Say this first: "Match the integration speed to the business decision speed. Real-time is expensive; everything else should be batch or event-driven. And make every write safe to repeat."

A: Real-time integrations consume API limits, require complex error handling, and tightly couple systems. It only earns its place if:

• A user is physically waiting on the screen for a response.
• The business decision is invalid if the data is more than a few minutes old.

For everything else, "real-time" usually just means "fast enough." Pushing updates via events within 5 minutes satisfies most business needs.

To make retries safe (Idempotency):

• Always upsert based on an External ID rather than doing blind inserts.
• Include an Idempotency Key (a unique transaction ID) on outbound messages so the receiving system knows if it's processing a duplicate.
• Assume the network will fail. Design error queues with replay capabilities, rather than fire-and-lose.

Q: What is your standard error-handling design for an integration?

A: A robust integration error framework consists of three layers:

• Capture: Every failure writes a custom log record containing the payload reference, the exact error message, the target Record ID, and a correlation ID for tracing.
• Alert: Threshold-based alerts notify the responsible development or admin team (not just a shared inbox that gets ignored).
• Replay/Recovery: Failed messages sit in a designated queue or custom object with an automated or manual "re-run" action.
• Handling Partial Success: If using APIs where allOrNone = false, you must handle errors on a per-row basis. Map every failed row back to its source record so successes don't mask underlying failures.