Integration Patterns

Salesforce defines six canonical integration patterns. Every CTA scenario requires you to select and justify the right pattern for each integration touchpoint. This page covers all six patterns with sequence diagrams, selection criteria, and the trade-offs that matter at the review board.

Highest failure domain

Integration is the domain where CTA candidates fail most often. The review board expects you to name the pattern, justify it against alternatives, address error handling, and explain the timing (real-time vs near-real-time vs batch). Vague answers like “we’ll use an API” will cost you points.

The Six Patterns at a Glance

#	Pattern	Direction	Timing	Initiator	Common Tech
1	Remote Process Invocation — Request-Reply	SF to External	Real-time	Salesforce	REST/SOAP callout, Named Credentials
2	Remote Process Invocation — Fire-and-Forget	SF to External	Near-real-time	Salesforce	Platform Events, Outbound Messages, Async Apex
3	Batch Data Synchronization	Bidirectional	Batch	Either	Bulk API, ETL tools, MuleSoft batch
4	Remote Call-In	External to SF	Real-time	External	REST/SOAP API, Composite API
5	UI Update Based on Data Changes	External to SF	Real-time	External	Streaming API, Platform Events, Pub/Sub API
6	Data Virtualization	SF to External	Real-time	Salesforce	Salesforce Connect, External Objects

Pattern 1: Remote Process Invocation — Request-Reply

Salesforce calls an external system and waits for the response before proceeding. The calling process blocks until the reply arrives.

When to Use

User action requires immediate confirmation (e.g., credit check, address validation)
The external system response is needed before the transaction can commit
Latency is acceptable (external call must return within governor limits)

Sequence Diagram

sequenceDiagram
    participant User
    participant Salesforce
    participant External System

    User->>Salesforce: Triggers action (button click, record save)
    Salesforce->>External System: HTTP callout (REST/SOAP)
    Note over Salesforce,External System: Salesforce blocks, waiting for response
    External System-->>Salesforce: Response (success/failure + data)
    Salesforce->>Salesforce: Process response, update records
    Salesforce-->>User: Display result

Implementation Options

Option	Best For	Governor Limit
Apex Callout (synchronous)	Simple integrations, user-facing	Default 10s timeout per callout, configurable up to 120s; 120s cumulative per transaction
Flow HTTP Callout	Declarative, admin-managed	Same governor limits apply
External Services	OpenAPI-based services, no code	Auto-generates Apex from spec

Trade-offs

Advantage	Disadvantage
Immediate feedback to user	Blocks the transaction — poor UX if slow
Simple to reason about	Subject to governor limits (default 10s callout timeout, configurable up to 120s)
Transactional consistency	External system downtime = Salesforce failure
Easy error handling	Cannot handle high-volume scenarios

CTA board defense

Always pair Request-Reply with a fallback strategy. What happens when the external system is down? Options: graceful degradation (show cached data), circuit breaker pattern, or retry with user notification.

Pattern 2: Remote Process Invocation — Fire-and-Forget

Salesforce sends a message to an external system and does not wait for a response. Processing continues asynchronously.

When to Use

The response is not needed immediately (e.g., order fulfillment, notification dispatch)
You need to decouple Salesforce from external system availability
Volume or latency makes synchronous calls impractical

Sequence Diagram

sequenceDiagram
    participant User
    participant Salesforce
    participant Message Bus
    participant External System

    User->>Salesforce: Triggers action
    Salesforce->>Message Bus: Publish event/message
    Salesforce-->>User: Immediate confirmation
    Note over User,Salesforce: User is not blocked
    Message Bus->>External System: Deliver message (async)
    External System->>External System: Process message
    External System-->>Salesforce: Optional callback (if needed)

Implementation Options

Option	Best For	Delivery Guarantee
Platform Events	Event-driven architectures	At-least-once (with replay)
Outbound Messages	Workflow-triggered SOAP calls	At-least-once (retries for 24h)
Queueable Apex with Callout	Complex logic before callout	No built-in retry
Change Data Capture	Data change notifications	At-least-once (with replay)

Trade-offs

Advantage	Disadvantage
Decouples systems	No immediate confirmation of success
Salesforce transaction unaffected by external failures	Requires monitoring for failed deliveries
Better UX (no waiting)	Eventual consistency — data may lag
Handles higher volumes	More complex error handling needed

Idempotency is mandatory

Fire-and-forget patterns deliver at-least-once, meaning duplicates are possible. The external system MUST be idempotent — processing the same message twice should produce the same result. Use idempotency keys or deduplication logic.

Pattern 3: Batch Data Synchronization

Large volumes of data are synchronized between systems on a scheduled basis. This is the workhorse pattern for data warehousing, reporting sync, and initial data loads.

When to Use

Data does not need to be current to the second (hours-old data is acceptable)
Volume exceeds what real-time APIs can handle efficiently
Regular data reconciliation between systems
Data migration or initial load scenarios

Sequence Diagram

sequenceDiagram
    participant Scheduler
    participant ETL/Middleware
    participant Source System
    participant Salesforce

    Scheduler->>ETL/Middleware: Trigger batch job (cron/schedule)
    ETL/Middleware->>Source System: Extract changed records
    Source System-->>ETL/Middleware: Return dataset
    ETL/Middleware->>ETL/Middleware: Transform & validate data
    ETL/Middleware->>Salesforce: Load via Bulk API 2.0
    Salesforce-->>ETL/Middleware: Job results (success/failure counts)
    ETL/Middleware->>ETL/Middleware: Log results, handle failures

Implementation Options

Option	Volume	Direction
Bulk API 2.0	Millions of records	Inbound to SF
Data Loader (CLI mode)	Thousands to millions	Bidirectional
MuleSoft Batch Module	Enterprise-scale	Bidirectional
Informatica Cloud	Enterprise-scale	Bidirectional
Scheduled Apex + SOQL	Moderate volumes	SF-initiated

Volume Thresholds

Volume	Recommended Approach
< 2,000 records	REST API (single requests or Composite)
2,000 - 50,000 records	Bulk API 2.0 (serial mode)
50,000 - 10M records	Bulk API 2.0 (parallel mode) with middleware
10M+ records	Bulk API 2.0 + partitioning + off-peak scheduling

Trade-offs

Advantage	Disadvantage
Handles massive volumes efficiently	Data is stale between sync windows
Predictable resource consumption	Requires scheduling and monitoring
Can run during off-peak hours	Complex error handling for partial failures
Well-understood pattern	Change detection logic needed (deltas vs full loads)

Pattern 4: Remote Call-In

An external system initiates a call into Salesforce. Salesforce is the target, not the initiator.

When to Use

External system owns the process and needs to create/update/read Salesforce data
ERP pushes order updates into Salesforce
Web application or mobile app reads/writes Salesforce data
External system needs to invoke business logic hosted in Salesforce

Sequence Diagram

sequenceDiagram
    participant External System
    participant Salesforce API
    participant Salesforce Logic

    External System->>Salesforce API: Authenticate (OAuth 2.0)
    Salesforce API-->>External System: Access token
    External System->>Salesforce API: API request (REST/SOAP/Composite)
    Salesforce API->>Salesforce Logic: Execute business logic, triggers, flows
    Salesforce Logic-->>Salesforce API: Result
    Salesforce API-->>External System: Response (data + status)

Implementation Options

Option	Best For	Consideration
REST API	Modern integrations, JSON payloads	Most common choice
SOAP API	Legacy systems, WSDL-based clients	Higher overhead, full metadata access
Composite API	Multi-step operations, reducing round trips	Up to 25 subrequests
GraphQL API	Flexible queries and mutations, mobile-friendly	Newer; mutations GA in API v66.0 (Spring ‘26)
Apex REST/SOAP Services	Custom business logic endpoints	Full control, governor limits apply

Trade-offs

Advantage	Disadvantage
External system controls timing and logic	Salesforce API limits apply (daily and concurrent)
Full access to Salesforce data model	Authentication complexity (OAuth flows)
Can leverage Salesforce business logic	Governor limits on custom Apex endpoints
Standard API protocols	External system must handle retries

Connected App governance

Every Remote Call-In requires a Connected App for OAuth. In CTA scenarios, plan for: which OAuth flow (JWT Bearer for server-to-server, Web Server for user-context), token refresh strategy, and scope restrictions.

Pattern 5: UI Update Based on Data Changes

The external system (or Salesforce UI) needs to react in near-real-time when data changes in Salesforce — without polling.

When to Use

Dashboard or UI needs to reflect changes as they happen
External system must react to Salesforce data changes within seconds
Polling is not acceptable due to API limit consumption or latency requirements
Event-driven architecture where consumers subscribe to change streams

Sequence Diagram

sequenceDiagram
    participant User
    participant Salesforce
    participant Event Bus
    participant Subscriber (UI/External)

    User->>Salesforce: Creates/updates record
    Salesforce->>Event Bus: Publish change event
    Event Bus->>Subscriber (UI/External): Push notification
    Subscriber (UI/External)->>Subscriber (UI/External): Update UI / trigger process
    Note over Event Bus,Subscriber (UI/External): No polling -- push-based delivery

Implementation Options

Option	Best For	Retention
Change Data Capture (CDC)	Any standard/custom object changes	3 days
Platform Events	Custom business events	72 hours (high-volume)
Pub/Sub API (gRPC)	High-throughput external subscribers	Depends on event type
Streaming API (legacy)	LWC Empiri API subscriptions	Being replaced by Pub/Sub

Trade-offs

Advantage	Disadvantage
Near-real-time updates	24-72 hour event retention limit
No polling (saves API calls)	Subscriber must handle reconnection
Push-based, event-driven	At-least-once delivery (duplicates possible)
Scalable to many subscribers	Replay window is finite

Pattern 6: Data Virtualization

Data stays in the external system and is accessed on-demand from Salesforce without copying it into Salesforce. Salesforce Connect and External Objects provide the framework.

When to Use

Data is too large to replicate into Salesforce (LDV concerns)
Data changes too frequently to keep copies in sync
Regulatory or compliance requirements prevent data duplication
You need to display external data in Salesforce UI with minimal effort
External system is the system of record and data should not be duplicated

Sequence Diagram

sequenceDiagram
    participant User
    participant Salesforce UI
    participant External Object
    participant External System

    User->>Salesforce UI: Views related list / report
    Salesforce UI->>External Object: Query external object
    External Object->>External System: OData / Custom Adapter call
    External System-->>External Object: Return data
    External Object-->>Salesforce UI: Display data inline
    Note over User,Salesforce UI: Data is never stored in Salesforce

Implementation Options

Adapter	Protocol	Best For
OData 2.0 / 4.0	OData	SAP, SharePoint, any OData-compliant system
Cross-org Adapter	Salesforce-to-Salesforce	Multi-org architectures
Custom Adapter (Apex)	Any	Proprietary APIs, complex auth

Trade-offs

Advantage	Disadvantage
No data duplication	Slower than native objects (network latency per query)
Always current data	Limited Salesforce functionality (no triggers, limited reports)
No storage costs	Cannot use in all SOQL contexts
Regulatory compliance	External system must be highly available
Quick to implement	No offline access

Know the limitations

External Objects cannot participate in: Apex triggers, process builders, most flow operations, approval processes, or standard reports. If the scenario requires any of these, Data Virtualization is NOT the right pattern. This is a common trap in CTA scenarios.

Timing: Real-Time vs Near-Real-Time vs Batch

Choosing the right timing is a critical CTA decision. The choice depends on business requirements, data volume, and acceptable staleness.

flowchart TD
    A[Integration Need Identified] --> B{Does the user need<br/>immediate feedback?}
    B -->|Yes| C{Can the external system<br/>respond within 10 seconds?}
    C -->|Yes| D[Real-Time<br/>Request-Reply]
    C -->|No| E{Can the user wait<br/>for a callback?}
    E -->|Yes| F[Near-Real-Time<br/>Fire-and-Forget + Callback]
    E -->|No| G[Consider Data<br/>Virtualization]
    B -->|No| H{Volume > 2000 records<br/>per transaction?}
    H -->|Yes| I[Batch Data<br/>Synchronization]
    H -->|No| J{Is data change-driven?}
    J -->|Yes| K[Near-Real-Time<br/>Event-Driven CDC/Platform Events]
    J -->|No| L[Scheduled Near-Real-Time<br/>or Batch]

Timing	Latency	Volume	Use Case
Real-time	< 2 seconds	Single records	Address validation, credit check
Near-real-time	2 seconds - 5 minutes	Low-moderate	Order status updates, notifications
Batch	Minutes to hours	High (thousands+)	Data warehouse sync, reporting

Combining Patterns in CTA Scenarios

Real-world CTA scenarios always require multiple patterns. A typical enterprise integration landscape might use:

Request-Reply for real-time address validation at point of sale
Fire-and-Forget for order fulfillment notifications to the warehouse
Batch Sync for nightly data warehouse updates
Remote Call-In for the ERP pushing invoice updates into Salesforce
CDC/Events for the customer portal reacting to case status changes
Data Virtualization for displaying legacy product catalog without migration

CTA board strategy

When presenting integration architecture, create a table mapping each integration touchpoint to its pattern, timing, technology, and error handling strategy. This demonstrates systematic thinking and makes it easy for judges to follow your reasoning.

Touchpoint	Pattern	Timing	Technology	Error Strategy
Address Validation	Request-Reply	Real-time	REST callout	Graceful degradation
Order to ERP	Fire-and-Forget	Near-RT	Platform Events + MuleSoft	DLQ + retry
Data Warehouse	Batch Sync	Nightly	Bulk API 2.0 + Informatica	Partial failure handling
ERP Invoice Sync	Remote Call-In	Real-time	REST API	Idempotency keys
Portal Notifications	UI Update	Near-RT	CDC + Pub/Sub API	Replay from checkpoint
Legacy Catalog	Virtualization	On-demand	Salesforce Connect OData	Fallback cache

Enterprise Integration Landscape

A real CTA scenario never involves a single integration. The diagram below shows how multiple patterns coexist in a typical enterprise, with Salesforce at the center coordinating real-time, near-real-time, and batch data flows through a mix of direct and middleware-mediated connections.

flowchart TB
    subgraph Legend
        direction LR
        L1[🟢 NEW]
        L2[⚪ KEEPING]
        L3[🔴 RETIRING]
        L4[🟠 INTEGRATION LAYER]
    end

    subgraph External["External Systems"]
        ERP["SAP ERP"]
        DW["Data Warehouse"]
        PORTAL["Customer Portal"]
        ADDR["Address Service"]
        LEGACY["Legacy Mainframe"]
        BILLING["Billing Platform"]
        MARKETING["Marketing Cloud"]
    end

    subgraph MW["Integration Layer — MuleSoft Anypoint"]
        direction TB
        SYS_API["System APIs"]
        PROC_API["Process APIs"]
        EXP_API["Experience APIs"]
        SYS_API --> PROC_API --> EXP_API
    end

    subgraph SF["Salesforce Platform"]
        direction TB
        CORE["Sales & Service Cloud"]
        EB["Event Bus<br/>Platform Events / CDC"]
        EXTOBJ["External Objects<br/>Salesforce Connect"]
    end

    %% Pattern 1: Request-Reply (direct)
    CORE -->|"P1: Request-Reply<br/>Real-time REST callout"| ADDR

    %% Pattern 2: Fire-and-Forget (via event bus + middleware)
    EB -->|"P2: Fire-and-Forget<br/>Platform Events"| SYS_API
    SYS_API -->|"Route & transform<br/>order data"| ERP

    %% Pattern 3: Batch (via middleware)
    PROC_API -->|"P3: Batch Sync<br/>Bulk API 2.0 nightly"| DW

    %% Pattern 4: Remote Call-In (via middleware)
    BILLING -->|"P4: Remote Call-In<br/>REST API"| SYS_API
    SYS_API -->|"Composite API<br/>invoice upsert"| CORE

    %% Pattern 5: UI Update (CDC direct)
    EB -->|"P5: UI Update<br/>CDC + Pub/Sub API"| PORTAL

    %% Pattern 6: Data Virtualization
    EXTOBJ -.->|"P6: Virtualization<br/>OData on-demand"| LEGACY

    %% Marketing direct
    CORE -->|"Near-RT CDC<br/>contact sync"| MARKETING

    style MW fill:#e65100,color:#fff
    style SYS_API fill:#e65100,color:#fff
    style PROC_API fill:#e65100,color:#fff
    style EXP_API fill:#e65100,color:#fff
    style CORE fill:#1565c0,color:#fff
    style EB fill:#1565c0,color:#fff
    style EXTOBJ fill:#1565c0,color:#fff
    style ERP fill:#868e96,color:#fff
    style DW fill:#868e96,color:#fff
    style PORTAL fill:#868e96,color:#fff
    style ADDR fill:#868e96,color:#fff
    style LEGACY fill:#868e96,stroke-dasharray:5 5,color:#fff
    style BILLING fill:#868e96,color:#fff
    style MARKETING fill:#868e96,color:#fff

Reading the landscape diagram

Notice the hybrid approach: simple integrations (address validation, portal CDC) connect directly, while complex multi-system flows (ERP, billing, data warehouse) route through middleware. The event bus serves as the internal decoupling layer. This hybrid pattern is the answer that wins at the CTA board — it shows cost-consciousness without sacrificing governance where it matters.

Data Migration — batch data sync and migration patterns often drive integration pattern selection
Identity & SSO — authentication and authorization for integration endpoints (Named Credentials, OAuth flows)
CI/CD & Deployment — deploying integration configurations (connected apps, Named Credentials, remote site settings)

Sources

Salesforce Integration Patterns and Practices (Official)
Salesforce Architects: Integration Patterns
Salesforce Architects: System Landscape Reference Architecture
Trailhead: Integration Architecture
Trailhead: Application Integration Patterns
Andrew Fawcett, “Salesforce Platform Enterprise Architecture” (Packt)
CTA Study Group community notes on integration pattern selection

Integration Patterns

The Six Patterns at a Glance

Pattern 1: Remote Process Invocation — Request-Reply

When to Use

Sequence Diagram

Implementation Options

Trade-offs

Pattern 2: Remote Process Invocation — Fire-and-Forget

When to Use

Sequence Diagram

Implementation Options

Trade-offs

Pattern 3: Batch Data Synchronization

When to Use

Sequence Diagram

Implementation Options

Volume Thresholds

Trade-offs

Pattern 4: Remote Call-In

When to Use

Sequence Diagram

Implementation Options

Trade-offs

Pattern 5: UI Update Based on Data Changes

When to Use

Sequence Diagram

Implementation Options

Trade-offs

Pattern 6: Data Virtualization

When to Use

Sequence Diagram

Implementation Options

Trade-offs

Timing: Real-Time vs Near-Real-Time vs Batch

Combining Patterns in CTA Scenarios

Enterprise Integration Landscape

Related Content

Sources