Integration Patterns: Quick Reference

All 6 official Salesforce integration patterns on one page, plus a selection matrix, timing guide, and middleware decision framework. For full details with sequence diagrams, see Integration Patterns Deep Dive.

The 6 Patterns — Master Table

#	Pattern	Direction	Timing	Tech	Error Strategy	Use When
1	Request-Reply	SF —> External	Real-time	REST/SOAP callout, Named Credentials	Circuit breaker + graceful degradation	User needs immediate response (validation, credit check)
2	Fire-and-Forget	SF —> External	Near-RT	Platform Events, Outbound Messages	Retry + DLQ + idempotency	Response not needed now (order fulfillment, notifications)
3	Batch Data Sync	Bidirectional	Batch	Bulk API 2.0, ETL tools	Partial failure handling + reconciliation	High volume, data freshness in hours is OK
4	Remote Call-In	External —> SF	Real-time	REST/SOAP/Composite API	Idempotency keys + rate limiting	External system owns the process (ERP push, portal writes)
5	UI Update (Data Changes)	SF —> Subscriber	Near-RT	CDC, Platform Events, Pub/Sub API	Replay from checkpoint + subscriber monitoring	React to changes without polling (dashboards, portals)
6	Data Virtualization	SF —> External	On-demand	Salesforce Connect, External Objects	Fallback cache + high-availability external system	Display external data without replication

Pattern Selection Flowchart

flowchart TD
    A[Integration Need] --> B{Who initiates?}
    B -->|Salesforce| C{Need response<br/>to continue?}
    C -->|Yes| D{External responds<br/>within 10s?}
    D -->|Yes| E["P1: Request-Reply"]
    D -->|No| F{Can virtualize<br/>the data?}
    F -->|Yes| G["P6: Data Virtualization"]
    F -->|No| H["P2: Fire-and-Forget<br/>+ callback"]
    C -->|No| I{Volume > 2K<br/>records?}
    I -->|Yes| J["P3: Batch Sync"]
    I -->|No| K["P2: Fire-and-Forget"]
    B -->|External System| L{Reacting to SF<br/>data changes?}
    L -->|Yes| M["P5: UI Update / CDC"]
    L -->|No| N["P4: Remote Call-In"]

    style E fill:#e8f5e9
    style G fill:#e3f2fd
    style H fill:#fff3e0
    style J fill:#f3e5f5
    style K fill:#fff3e0
    style M fill:#e3f2fd
    style N fill:#e8f5e9

Timing Quick-Decision Table

Business Need	Timing	Default Pattern	Default Tech
User waiting for answer	Real-time (< 2s)	Request-Reply	REST callout
Process can continue without answer	Near-RT (seconds-minutes)	Fire-and-Forget	Platform Events
Data sync, reporting refresh	Batch (hours)	Batch Data Sync	Bulk API 2.0
Display external data inline	On-demand	Data Virtualization	Salesforce Connect
External system pushes to SF	Real-time	Remote Call-In	REST API
React to SF changes externally	Near-RT	UI Update	CDC + Pub/Sub API

The #1 board mistake on patterns

Saying “we’ll use an API” without naming the pattern. Always say: “This is a Fire-and-Forget pattern using Platform Events through MuleSoft, with exponential backoff retry and a dead letter queue for failures.” Name the pattern, the tech, and the error strategy in one sentence.

Middleware Decision Framework

When to Recommend Middleware

Systems	Recommendation	Rationale
2 systems, simple	Point-to-point	Middleware adds cost with no benefit
2 systems, will grow	Consider middleware	Future-proofing may justify early investment
3-5 systems	Hybrid	Middleware for complex, P2P for simple
6+ systems	Middleware	Centralized governance, reuse, monitoring

MuleSoft API-Led Connectivity (3 Layers)

flowchart TB
    subgraph EXP["Experience APIs"]
        E1[Mobile API] ~~~ E2[Web API] ~~~ E3[Partner API]
    end
    subgraph PROC["Process APIs"]
        P1[Order Processing] ~~~ P2[Customer 360]
    end
    subgraph SYS["System APIs"]
        S1[Salesforce] ~~~ S2[SAP] ~~~ S3[Database]
    end
    EXP --> PROC --> SYS

    style EXP fill:#e3f2fd
    style PROC fill:#fff3e0
    style SYS fill:#e8f5e9

Layer	Purpose	Owned By	Example
System	Expose backend as reusable API	Backend teams	”Salesforce Contact API”
Process	Orchestrate across System APIs + business logic	Integration team	”Customer 360 API”
Experience	Tailor for consumer (mobile, web, partner)	Consumer teams	”Mobile Customer API”

Why three layers matters at the board

It is not a MuleSoft marketing term — it is an architecture principle. It enables: reusability (System APIs shared by many Process APIs), agility (change Process without touching backends), governance (clear ownership per layer). Lead with benefits, not product names.

Middleware Platform Comparison

Factor	MuleSoft	Dell Boomi	Informatica	Workato
Best for	Complex enterprise, API programs	Mid-market, rapid deploy	Data-heavy, MDM	Business process automation
SF alignment	Native (SF-owned)	Strong connector	Strong connector	Good connector
Cost	$$$	$$	$$-$$$	$$
When to recommend	Default for SF-heavy	MuleSoft cost prohibitive	Data quality is primary	Business users manage integrations

Reverse-Engineered Use Cases

Scenario 1: Insurance Claims Processing

Situation: Insurance company with Salesforce (CRM), Guidewire (claims), SAP (finance), and a customer portal. Claims status must appear on the portal within 30 seconds of update.

What you’d present:

• Guidewire —> SF: Remote Call-In (REST API) for claim creation
• SF claim status change —> Portal: UI Update (CDC + Pub/Sub API) for near-RT push
• SF —> SAP: Fire-and-Forget (Platform Events + MuleSoft) for payment processing
• Nightly reconciliation: Batch Sync (Bulk API 2.0 + MuleSoft batch)
• Middleware justified: 4 systems, shared transformations, centralized monitoring

Scenario 2: Retail POS Integration

Situation: Retail chain needs real-time inventory checks at point of sale. External inventory system response time averages 800ms. 500 stores, peak of 2,000 checks/hour.

What you’d present:

• POS —> Inventory check: Request-Reply (REST callout, < 1s response)
• Fallback when inventory system is down: Circuit breaker opens, show cached inventory with staleness warning
• Daily inventory sync: Batch Sync (Bulk API 2.0) to refresh cache and reconcile
• No middleware needed: Only 2 systems, simple payload, no transformation

Scenario 3: Multi-Cloud Healthcare Platform

Situation: Healthcare org with Salesforce Health Cloud, Epic (EHR), Snowflake (analytics), and a patient portal. HIPAA compliance required. 50+ integration touchpoints planned.

What you’d present:

• Epic —> SF: Remote Call-In (FHIR/REST API) for patient data sync
• SF —> Patient Portal: UI Update (Platform Events, not CDC — custom event semantics for HIPAA-filtered payload)
• SF —> Snowflake: Batch Sync (Bulk API 2.0 + MuleSoft batch, nightly)
• MuleSoft mandatory: 50+ touchpoints, HIPAA audit trails, API governance, reusability across experience layer

Data Virtualization trap

External Objects support after insert/update/delete Apex triggers when change tracking is enabled. They cannot participate in approval processes or standard reports. If the scenario requires approval processes or standard reporting on external data, Data Virtualization is the wrong pattern. Replicate the data instead using Batch Sync.

Multi-Org Integration

When the scenario involves multiple Salesforce orgs (common in M&A, global enterprises, franchise models):

Approach	Best For	Limitations
Salesforce Connect (Cross-Org Adapter)	Read-only access to another org’s data without replication	No DML on external objects, no triggers, limited reporting
Platform Events (Cross-Org)	Near-real-time business event sharing between orgs	Requires Connected App auth between orgs, event retention limits
Salesforce-to-Salesforce	Native record sharing between orgs with subscription model	Being retired — use Salesforce Connect cross-org adapter or API-based integration instead

Reverse-Engineered Use Case: M&A Consolidation

Situation: Parent company acquires a subsidiary running its own Salesforce org. Parent needs consolidated reporting on Accounts and Opportunities across both orgs while the subsidiary operates independently during a 12-month integration period. What you’d present: Salesforce Connect cross-org adapter for read-only consolidated views in the parent org. Platform Events for near-RT sync of key business events (e.g., large deal closed). Batch Sync via Bulk API + MuleSoft for nightly reconciliation. After the integration period, migrate subsidiary data into the parent org and decommission the subsidiary org.

Default Decisions Cheat Sheet

Decision	Default	Override When
Sync vs Async	Async	User is blocked without immediate response
Middleware vs P2P	P2P (< 4 systems)	4+ systems, complex transforms, governance
REST vs SOAP	REST	Legacy WSDL requirement
ETL vs ELT	ETL (transform outside SF)	Trivial transforms or SF-native logic needed
Timing	Batch (cheapest)	Business requires fresher data
Events	CDC for data changes	Custom semantics or external publish needed

Sources

• Salesforce Integration Patterns (Spring ‘26 Official)
• Salesforce Architect — Integration Patterns
• MuleSoft API-Led Connectivity
• Trailhead — Integration Architecture
• CTA Board Judge Insights — DYDC