Integration Patterns

Salesforce defines six canonical integration patterns. Every CTA scenario requires selecting and justifying the right pattern for each integration touchpoint. All six are covered here with sequence diagrams, selection criteria, and the trade-offs that matter at the review board.

Highest failure domain

Integration is 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” cost 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

Use Request-Reply when a user action cannot proceed without an external system’s answer: credit checks, address validation, real-time pricing. The calling process blocks until the reply arrives. This pattern only works when latency is acceptable (the external system must respond within governor limits) and the transaction depends on the result before committing.

Sequence Diagram

Figure 1. The Request-Reply pattern blocks the Salesforce transaction until the external system responds. Use only when the business process cannot proceed without the external answer and the external system reliably responds within governor limit windows.

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

Use Fire-and-Forget when the business process does not need an immediate answer: order fulfillment handoffs, notification dispatches, audit logging to external systems. Salesforce publishes a message and moves on. The user is never blocked by downstream latency or outages. Prefer this over Request-Reply when volume or latency makes synchronous calls impractical.

Sequence Diagram

Figure 2. Fire-and-Forget decouples Salesforce from downstream latency by publishing to a message bus and returning control immediately. The external system processes on its own schedule, requiring idempotent consumers to handle at-least-once delivery.

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.

CTA Exam Relevance

The board probes error handling depth when you propose Fire-and-Forget. Saying “we publish a Platform Event” is not enough. Be ready to answer: What monitors for failed deliveries? Where do unprocessable messages go (dead letter queue)? How do you replay missed events after an outage? What is your idempotency strategy? These details separate passing answers from failing ones.

---

Pattern 3: Batch Data Synchronization

Use Batch Sync when data staleness of minutes to hours is acceptable and volume exceeds what real-time APIs handle efficiently. This is the workhorse for data warehousing, reporting sync, initial data loads, and cross-system reconciliation. If the business requires data current to the second, this is the wrong pattern. Use event-driven (Pattern 5) or Request-Reply (Pattern 1) instead.

Sequence Diagram

Figure 3. Batch Synchronization uses scheduled ETL jobs and Bulk API 2.0 to move high-volume data efficiently. Transformation outside Salesforce avoids governor limits, and delta extraction keeps job windows manageable as data grows.

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

Use Remote Call-In when the external system owns the process and needs to create, update, or read Salesforce data on its own schedule. The ERP pushes invoice updates. The web portal reads customer records. The external scoring engine invokes Salesforce business logic. In each case, Salesforce is the target, not the initiator. This is the default pattern when Salesforce should not poll for changes.

Sequence Diagram

Figure 4. Remote Call-In places the external system in control of timing and frequency. API limit governance and Connected App OAuth configuration are the primary architectural concerns when multiple external systems call into the same org.

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 use 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.

CTA Exam Relevance

The board frequently probes Remote Call-In with questions about API limit governance, especially when multiple external systems call Salesforce. Be ready to answer: How many concurrent API calls can the org handle? What happens when the daily API limit is approached? How do you prioritize critical integrations over non-critical ones? Proposing API rate limiting through the middleware layer shows enterprise-level thinking.

---

Pattern 5: UI Update Based on Data Changes

Use this pattern when an external system or Salesforce UI must react to data changes within seconds, without polling. Polling wastes API limits and adds latency; push-based delivery solves both problems. The right fit when dashboards must reflect changes as they happen, external systems must react to Salesforce record changes in near-real-time, or consumers subscribe to change streams.

Sequence Diagram

Figure 5. The UI Update pattern eliminates polling by pushing change events directly to subscribers. CDC and Platform Events share the same event bus infrastructure, with retention windows of 3 days and 72 hours respectively.

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 Emp 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

Use Data Virtualization when copying data into Salesforce is impractical or prohibited: the dataset is too large (LDV concerns), changes too frequently to keep copies in sync, or regulatory/compliance rules prevent data duplication. Salesforce Connect and External Objects query the data on-demand without storing it. Also the right fit when the external system is the authoritative system of record and you only need to display its data in Salesforce UI.

Sequence Diagram

Figure 6. Data Virtualization queries the external system on demand through Salesforce Connect, eliminating data duplication and storage costs. External Objects cannot participate in Apex triggers, approval processes, or most Flow operations.

Implementation Options

Adapter	Protocol	Best For
OData 2.0 / 4.0	OData	SAP, SharePoint, any OData-compliant system
Cross-org Adapter	Salesforce org-to-org	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

Timing is a critical CTA decision. The choice depends on business requirements, data volume, and acceptable staleness.

Figure 7. Timing selection starts with whether the user is blocked waiting for a result, then evaluates response-time feasibility, volume thresholds, and whether the trigger is a data change. Each branch maps to a specific pattern and technology stack.

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

CTA Exam Relevance

The board tests whether you can justify timing choices per integration touchpoint, not just name the pattern. A common failing answer is “near-real-time” for everything. Defend each timing choice with the specific business requirement: “The warehouse needs order data within 30 minutes, not seconds, so near-real-time via Platform Events works and avoids the cost of real-time synchronous calls.”

---

Combining Patterns in CTA Scenarios

Real CTA scenarios always need multiple patterns. A typical enterprise integration setup 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: Salesforce at the center, coordinating real-time, near-real-time, and batch data flows through a mix of direct and middleware-mediated connections.

Figure 8. A realistic enterprise uses all six patterns simultaneously. Simple two-system integrations (address validation, portal CDC) connect directly; complex multi-system flows route through MuleSoft API-led layers. The event bus decouples Salesforce from downstream processing.

Detailed walkthrough

Not every integration in this diagram crosses the middleware band, and that asymmetry is the central lesson.

The P1 arrow runs directly from Salesforce Core to the Address Service, bypassing MuleSoft. Address validation is synchronous with one consumer: the callout blocks until the response arrives and the result is needed before the record saves. Routing it through middleware adds a hop and a failure point with no gain. The failure mode is the external system going down mid-transaction: the Apex callout times out (up to 120 seconds) and the transaction fails. A circuit breaker or graceful degradation to cached postal data is the correct board answer.

The P2 arrow leaves from the Event Bus, not Salesforce Core directly. When an order record is saved, a Platform Event fires into the internal event bus. MuleSoft subscribes via the System API tier, transforms the payload into SAP’s format, and routes it to the ERP. The user gets a confirmation immediately; ERP processing happens asynchronously. If MuleSoft is down during the event retention window, messages are at risk. The answer is replay from checkpoint using the event’s replay ID, plus a dead-letter queue for messages that exhaust retries.

The P3 arrow connects the Process API tier to the Data Warehouse via Bulk API 2.0 on a nightly schedule. The batch runs through the middle tier because the same Process API can serve other analytics consumers without additional Salesforce callouts.

The P4 path runs in reverse: Billing Platform calls MuleSoft’s System API, which calls Salesforce Core via Composite API to upsert invoices. Three or more consumers sharing a single integration point is the threshold where middleware governance pays off.

The P5 arrow goes directly from the Event Bus to the Customer Portal via CDC and Pub/Sub API. The portal is a single subscriber and the near-real-time requirement is met without middleware. CDC’s 3-day retention window gives the subscriber a meaningful replay buffer if it loses connectivity.

The P6 dotted arrow signals that no data physically moves. Salesforce queries the mainframe on demand through an OData adapter. No ETL, no duplication, no storage cost, but also no Apex triggers on the external object, limited flow support, and no full SOQL join semantics with native objects.

Pattern selection is per touchpoint, not per platform. Mandating that everything goes through MuleSoft fails because it ignores the Address Service and Portal CDC cases where middleware is pure overhead.

Reading the diagram

Simple integrations (address validation, portal CDC) connect directly. Complex multi-system flows (ERP, billing, data warehouse) route through middleware. The event bus acts as the internal decoupling layer. This hybrid pattern wins at the CTA board because it shows cost-consciousness without sacrificing governance where it matters.

---

Related Topics

• Data Migration: batch data sync and migration patterns often drive integration pattern selection
• Identity & SSO: authentication for integration endpoints (Named Credentials, OAuth flows)
• CI/CD & Deployment: deploying integration configs (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