Integration Decision Guides

CTA scenarios require rapid, defensible decisions about integration architecture. The decision trees below (as Mermaid flowcharts) cover the most common integration choices. Use them to practice decision-making and to structure reasoning at the review board.

How to use these guides

Each decision tree codifies first-principles reasoning. At the board, you will not have these charts, but having internalized the logic, you can walk judges through your reasoning step by step. Practice explaining WHY at each decision node, not just the final answer.

---

1. Synchronous vs Asynchronous

Pattern selection: Start by establishing whether the business process can proceed without the external system’s answer. If yes, the pattern is asynchronous — choose between Fire-and-Forget (any volume, no order requirement) and Batch Sync (large volume, acceptable staleness). If no, evaluate whether the external system can respond within governor limit windows at expected volume. If yes, Request-Reply is viable. If not, the board expects you to redesign the UX or use Data Virtualization. Wrong reasoning: choosing synchronous by default or because it is simpler to reason about. CTA-level reasoning: select based on business process dependency and volume math, not implementation familiarity.

Event-driven vs request-reply: The question is coupling tolerance, not just latency. Request-reply tightly couples the caller to the callee’s availability and response time. Event-driven accepts eventual consistency in exchange for loose coupling and independent scalability. Wrong reasoning: always preferring real-time because it feels safer or more consistent. CTA-level reasoning: event-driven is the correct default for integrations where the business process does not require an immediate answer, where volume will grow unpredictably, or where the subscriber landscape will expand over time. Request-reply earns its place when the transaction literally cannot commit without the external system’s answer.

The foundational integration timing decision. Get this wrong and the entire architecture suffers.

Figure 1. The synchronous vs asynchronous decision hinges on whether the calling process is blocked waiting for a result. When volume or latency rules out synchronous, evaluate UX redesign options before defaulting to async with a notification model.

Decision Factor	Synchronous	Asynchronous
User experience	Immediate feedback	Eventual notification
Coupling	Tight	Loose
Error handling	Direct	Complex (DLQ, monitoring)
Scalability	Limited by slowest system	Scales independently
Governor limits	10s callout, 120s total	No callout timeout pressure
Data consistency	Immediate	Eventual

---

2. Middleware vs Point-to-Point

Middleware vs direct integration: Evaluate each integration touchpoint independently, not the architecture as a whole. The question for each touchpoint is: does it require data transformation, fan out to multiple downstream systems, need centralized error handling, or connect to an external system that changes frequently? A “yes” to any pushes the touchpoint toward middleware. A “no” to all keeps it direct. Wrong reasoning: mandating that all integrations route through middleware (or none do). CTA-level reasoning: hybrid architecture with explicit per-touchpoint justification. The structural argument for middleware at scale is the n(n-1)/2 connection count — 10 systems point-to-point require 45 connections; with middleware, each system maintains one connection to the hub.

When to invest in middleware versus keeping things simple with direct integration.

Figure 2. Six or more systems always justify middleware. Between three and five systems, governance needs and shared transformations are the deciding factors. For two systems with no growth expectation and simple CRUD, point-to-point is the correct and cheaper answer.

Cost Comparison

Factor	Point-to-Point	Middleware (MuleSoft)
Initial cost	Low	High (licensing + setup)
Per-integration cost	Linear growth	Decreasing (reusable assets)
Maintenance at 3 integrations	Low	Higher than needed
Maintenance at 10 integrations	High (spaghetti)	Lower (centralized)
Monitoring	Per-integration	Centralized
Break-even point	N/A	Typically 5-8 integrations

---

3. REST vs SOAP

Protocol selection driven by consumer needs and system constraints.

Figure 3. REST is the default for unconstrained modern integrations. SOAP applies only when the consumer requires WSDL contracts. GraphQL fits mobile and bandwidth-sensitive consumers needing flexible queries; Composite API handles multi-step dependent operations in a single call.

Factor	REST	SOAP	GraphQL
Payload format	JSON (lightweight)	XML (verbose)	JSON (precise)
Contract	OpenAPI/Swagger (optional)	WSDL (strict)	Schema (strict)
Tooling	Universal	Mature but declining	Growing
Performance	Fast	Slower (XML parsing)	Optimized payloads
Mutations	Full CRUD	Full CRUD	Full CRUD (GA in API v66.0)
Learning curve	Low	Moderate	Moderate
Salesforce fit	Primary recommendation	Legacy or metadata	Mobile-optimized queries + mutations

---

4. ETL vs ELT vs Data Virtualization

Moving or accessing data across system boundaries.

Figure 4. Data that only needs to be displayed but not processed is a candidate for virtualization, avoiding replication entirely. When data must exist in Salesforce, ETL (transform outside before loading) is preferred over ELT to keep complex transformation logic away from Apex governor limits.

Approach	Transform Location	Best For	Salesforce Consideration
ETL	Middleware/staging area	Complex transformations, data cleansing	Preferred - avoids Apex governor limits
ELT	Target system (Salesforce)	Simple transforms, Salesforce-native logic	Limited by Apex processing limits
Virtualization	None (real-time query)	Display-only, highly volatile data	External Objects limitations apply

---

5. Which Salesforce API to Use

API type selection: Work through volume first. Any integration exceeding a few thousand records per operation should default to Bulk API 2.0, not REST. For lower volumes, the next questions are: does the consumer need flexible schema traversal (GraphQL), does the operation span multiple related records that would take multiple round trips (Composite API), or does the consumer need WSDL contracts (SOAP)? For event-driven scenarios, classify the event: record change notifications use CDC, custom business events use Platform Events, and high-throughput external consumers use Pub/Sub API. Wrong reasoning: defaulting to REST for everything, or choosing Streaming API (CometD) for new event-driven work. CTA-level reasoning: match API capabilities to the specific volume, direction, and interaction pattern of each integration.

API selection for any data operation.

Figure 5. Volume is the primary CRUD routing factor: under 200 records use REST, 200-2000 consider Composite or sObject Collections, and over 2000 always use Bulk API 2.0. Event-driven needs branch separately to CDC, Platform Events, or Pub/Sub API based on what triggers the change.

---

6. Real-Time vs Near-Real-Time vs Batch

Timing selection based on business requirements and technical constraints:

Figure 6. Data freshness requirements set the outer boundary; volume and user-blocking behavior narrow the choice within that boundary. Batch is the cheapest and simplest option and should be the default unless the business explicitly requires fresher data.

Timing	Latency	Typical Technology	Cost	Complexity
Real-time sync	< 2s	REST callout, External Services	High	Medium
Near-real-time	2s - 5min	Platform Events, CDC, Pub/Sub	Medium	Medium-High
Micro-batch	5-15 min	Scheduled Apex, middleware schedule	Medium	Medium
Batch	15min - 24h	Bulk API + ETL/middleware	Low	Low-Medium
On-demand	Variable	Salesforce Connect	Low	Low

---

7. Error Handling Strategy Selection

Selecting the right error handling approach based on integration characteristics.

Figure 7. Error strategy is not one-size-fits-all: synchronous user-facing integrations need graceful degradation, event-driven async patterns need idempotency and replay, and batch integrations need partial failure handling with reconciliation jobs. Each pattern has distinct monitoring metrics.

---

8. Platform Events vs Change Data Capture

A focused guide for the most commonly confused event technologies.

Figure 8. CDC is the right choice whenever you need automatic field-level change tracking on record DML with zero publish code. Platform Events apply when the event represents a business occurrence with custom semantics, or when an external system needs to publish events into Salesforce.

---

9. Authentication Flow Selection

For the full OAuth flow decision tree (all 6 flows with security comparison table), see Security Decision Guides - OAuth Flow Selection. The integration-specific question is direction:

• External system calls Salesforce: Select the OAuth flow based on user context - JWT Bearer for server-to-server, Web Server Flow for user-facing apps, Client Credentials for machine-to-machine without user context. See the full decision tree in Identity & SSO.
• Salesforce calls external system: Always use Named Credentials with the appropriate auth protocol. Named Credentials handle token management, refresh, and secure credential storage. Do not build custom auth in Apex.

---

Quick Reference: Decision Summary Table

Decision	Default Answer	Override When
Sync vs Async	Async (safer, more scalable)	User is blocked without immediate response
Middleware vs P2P	P2P for < 4 systems	4+ systems, complex transforms, governance needs
REST vs SOAP	REST	Legacy WSDL requirement or Partner WSDL needed
ETL vs ELT	ETL (transform outside SF)	Transformations are trivial or SF-native logic required
Which API	REST API	Volume > 2K (Bulk), events (Pub/Sub/CDC), multi-step (Composite)
Timing	Batch (cheapest, simplest)	Business requires fresher data
Error handling	Retry + DLQ + monitoring	Add circuit breaker for systemic failures
Auth flow	JWT Bearer for S2S, Web Server for users	No user context needed (Client Credentials)
Events	CDC for data changes, PE for business events	Custom semantics or external publishing needed

Board presentation technique

When presenting decision rationale, use a simple three-part formula: “I chose [option] over [alternative] because [specific scenario reason]. The trade-off is [downside], which I mitigate by [mitigation].” This demonstrates you considered alternatives and understand consequences.

---

Related Topics

• Solution Architecture Decision Guides: integration decisions intertwine with build-vs-buy and declarative-vs-code choices
• External Data: Salesforce Connect and External Objects are an integration pattern that requires data architecture decisions
• System Architecture Decision Guides: org strategy and platform decisions sit upstream of integration choices

---

Sources

• Salesforce Integration Patterns and Practices
• Salesforce Architect Decision Guides
• Trailhead: Integration Architecture
• MuleSoft: Integration Best Practices
• CTA coaching community decision frameworks