Skip to content
SF CTA Study Hub

Integration Decision Guides

CTA scenarios require rapid, defensible decisions about integration architecture. This page provides decision trees as Mermaid flowcharts for the most common integration choices. Use these to practice your decision-making process and to present clear reasoning at the review board.

How to use these guides

Each decision tree codifies the “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

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

flowchart TD
    A[Integration Need] --> B{Does the calling process<br/>need the response to continue?}
    B -->|Yes| C{Can the external system<br/>respond within 10 seconds?}
    C -->|Yes| D{Is the call volume<br/>manageable within<br/>API limits?}
    D -->|Yes| E["Synchronous (Request-Reply)"]
    D -->|No| F["Asynchronous with<br/>callback or polling"]
    C -->|No| G{Can you redesign the UX<br/>to not require<br/>immediate response?}
    G -->|Yes| H["Asynchronous<br/>(Fire-and-Forget + notification)"]
    G -->|No| I["Data Virtualization<br/>or cache + background refresh"]
    B -->|No| J{Is ordering important?}
    J -->|Yes| K["Asynchronous with<br/>ordered queue (FIFO)"]
    J -->|No| L["Asynchronous<br/>(Fire-and-Forget)"]

    style E fill:#e8f5e9
    style F fill:#fff3e0
    style H fill:#fff3e0
    style I fill:#e3f2fd
    style K fill:#fff3e0
    style L fill:#fff3e0
Decision FactorSynchronousAsynchronous
User experienceImmediate feedbackEventual notification
CouplingTightLoose
Error handlingDirectComplex (DLQ, monitoring)
ScalabilityLimited by slowest systemScales independently
Governor limits10s callout, 120s totalNo callout timeout pressure
Data consistencyImmediateEventual

2. Middleware vs Point-to-Point

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

flowchart TD
    A[New Integration] --> B{How many systems<br/>in the integration landscape?}
    B -->|2 systems| C{Will the landscape<br/>grow in 12 months?}
    C -->|No| D{Complex transformations<br/>needed?}
    D -->|No| E[Point-to-Point]
    D -->|Yes| F{Team has middleware<br/>expertise?}
    F -->|No| E
    F -->|Yes| G[Middleware]
    C -->|Yes| G
    B -->|3-5 systems| H{Centralized monitoring<br/>and governance needed?}
    H -->|No| I{Shared data<br/>transformations?}
    I -->|No| E
    I -->|Yes| G
    H -->|Yes| G
    B -->|6+ systems| G

    style E fill:#e8f5e9
    style G fill:#fff3e0

Cost Comparison

FactorPoint-to-PointMiddleware (MuleSoft)
Initial costLowHigh (licensing + setup)
Per-integration costLinear growthDecreasing (reusable assets)
Maintenance at 3 integrationsLowHigher than needed
Maintenance at 10 integrationsHigh (spaghetti)Lower (centralized)
MonitoringPer-integrationCentralized
Break-even pointN/ATypically 5-8 integrations

3. REST vs SOAP

Protocol selection based on consumer needs and system constraints.

flowchart TD
    A[API Protocol Decision] --> B{Consumer system<br/>constraint?}
    B -->|Requires WSDL/SOAP| C[SOAP API]
    B -->|No constraint| D{Need strong typing<br/>and contract-first?}
    D -->|Yes, critical| C
    D -->|No| E{Payload size<br/>concern?}
    E -->|Yes - minimize payload| F{Query flexibility<br/>needed?}
    F -->|Yes| G[GraphQL API]
    F -->|No| H[REST API]
    E -->|No| I{Need transaction<br/>support across<br/>multiple operations?}
    I -->|Yes| J[Composite API<br/>REST-based]
    I -->|No| H

    style C fill:#fff3e0
    style G fill:#e3f2fd
    style H fill:#e8f5e9
    style J fill:#e8f5e9
FactorRESTSOAPGraphQL
Payload formatJSON (lightweight)XML (verbose)JSON (precise)
ContractOpenAPI/Swagger (optional)WSDL (strict)Schema (strict)
ToolingUniversalMature but decliningGrowing
PerformanceFastSlower (XML parsing)Optimized payloads
MutationsFull CRUDFull CRUDRead-only (Salesforce)
Learning curveLowModerateModerate
Salesforce fitPrimary recommendationLegacy or metadataMobile-optimized queries

4. ETL vs ELT vs Data Virtualization

How to move or access data across system boundaries.

flowchart TD
    A[Data Integration Need] --> B{Does data need to<br/>exist in Salesforce?}
    B -->|No - just display it| C{External system<br/>highly available?}
    C -->|Yes| D[Data Virtualization<br/>Salesforce Connect]
    C -->|No| E[Replicate with<br/>ETL or ELT]
    B -->|Yes - for processing| F{Where should<br/>transformation happen?}
    F -->|In middleware/staging| G[ETL<br/>Extract-Transform-Load]
    F -->|In Salesforce| H[ELT<br/>Extract-Load-Transform]
    F -->|Minimal transformation| I{Volume?}
    I -->|High: 10K+| J[Bulk API 2.0<br/>with ETL tool]
    I -->|Low: < 10K| K[REST/Composite API<br/>direct load]

    style D fill:#e3f2fd
    style G fill:#e8f5e9
    style H fill:#fff3e0
    style J fill:#e8f5e9
    style K fill:#e8f5e9
ApproachTransform LocationBest ForSalesforce Consideration
ETLMiddleware/staging areaComplex transformations, data cleansingPreferred — avoids Apex governor limits
ELTTarget system (Salesforce)Simple transforms, Salesforce-native logicLimited by Apex processing limits
VirtualizationNone (real-time query)Display-only, highly volatile dataExternal Objects limitations apply

5. Which Salesforce API to Use

The comprehensive API selection guide for any data operation.

flowchart TD
    A[API Selection] --> B{What are you<br/>doing?}

    B -->|CRUD operations| C{Volume per<br/>transaction?}
    C -->|1-200 records| D{Multiple related<br/>operations?}
    D -->|Yes| E[Composite API]
    D -->|No| F[REST API]
    C -->|200-2000| G{Related records?}
    G -->|Yes| E
    G -->|No| H{Need real-time?}
    H -->|Yes| I[sObject Collections]
    H -->|No| J[Bulk API 2.0]
    C -->|2000+| J

    B -->|React to changes| K{What kind<br/>of changes?}
    K -->|Record data changes| L[Change Data Capture]
    K -->|Custom business events| M[Platform Events]
    K -->|External subscriber| N[Pub/Sub API]

    B -->|Deploy metadata| O[Metadata API]
    B -->|Developer tooling| P[Tooling API]
    B -->|Flexible queries| Q[GraphQL API]

    style E fill:#e8f5e9
    style F fill:#e8f5e9
    style I fill:#e8f5e9
    style J fill:#fff3e0
    style L fill:#e3f2fd
    style M fill:#e3f2fd
    style N fill:#e3f2fd
    style O fill:#f3e5f5
    style P fill:#f3e5f5
    style Q fill:#e3f2fd

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

Timing selection based on business requirements and technical constraints.

flowchart TD
    A[Data Synchronization Need] --> B{How fresh must<br/>the data be?}

    B -->|"Seconds (user is waiting)"| C{User blocked<br/>without response?}
    C -->|Yes| D[Real-Time<br/>Synchronous]
    C -->|No| E[Near-Real-Time<br/>Event-Driven]

    B -->|"Minutes (operational)"| F{Volume per<br/>minute?}
    F -->|Low: < 100| E
    F -->|High: 100+| G{Can batch<br/>every 5-15 min?}
    G -->|Yes| H[Micro-Batch<br/>Scheduled every N minutes]
    G -->|No| E

    B -->|"Hours (reporting/analytics)"| I{Volume?}
    I -->|Any| J[Batch<br/>Scheduled nightly/hourly]

    B -->|"Does not matter<br/>(on-demand)"| K[Data Virtualization<br/>Query on access]

    style D fill:#ffcdd2
    style E fill:#fff3e0
    style H fill:#fff3e0
    style J fill:#e8f5e9
    style K fill:#e3f2fd
TimingLatencyTypical TechnologyCostComplexity
Real-time sync< 2sREST callout, External ServicesHighMedium
Near-real-time2s - 5minPlatform Events, CDC, Pub/SubMediumMedium-High
Micro-batch5-15 minScheduled Apex, middleware scheduleMediumMedium
Batch15min - 24hBulk API + ETL/middlewareLowLow-Medium
On-demandVariableSalesforce ConnectLowLow

7. Error Handling Strategy Selection

Choosing the right error handling approach based on integration characteristics.

flowchart TD
    A[Integration Error<br/>Strategy Selection] --> B{Integration<br/>pattern?}

    B -->|Synchronous| C{User-facing?}
    C -->|Yes| D["Graceful Degradation<br/>+ user notification<br/>+ circuit breaker"]
    C -->|No| E["Retry with backoff<br/>+ circuit breaker<br/>+ DLQ"]

    B -->|Asynchronous| F{Event-driven?}
    F -->|Yes| G["At-least-once delivery<br/>+ idempotency keys<br/>+ replay from checkpoint"]
    F -->|No| H["Retry with backoff<br/>+ DLQ<br/>+ monitoring alerts"]

    B -->|Batch| I["Partial failure handling<br/>+ error records file<br/>+ reconciliation job"]

    D --> J[Monitor: Response time,<br/>circuit breaker state]
    E --> J
    G --> K[Monitor: Subscriber lag,<br/>DLQ depth, event replay gaps]
    H --> K
    I --> L[Monitor: Success/fail ratios,<br/>error record counts]

    style D fill:#e8f5e9
    style E fill:#fff3e0
    style G fill:#e3f2fd
    style H fill:#fff3e0
    style I fill:#f3e5f5

8. Platform Events vs Change Data Capture

A focused decision guide for the most commonly confused event technologies.

flowchart TD
    A[Need event-driven<br/>integration] --> B{What triggers<br/>the event?}

    B -->|Any record data change| C{Need field-level<br/>change tracking?}
    C -->|Yes| D[Change Data Capture]
    C -->|No| E{Custom semantics<br/>beyond CRUD?}
    E -->|Yes| F[Platform Events]
    E -->|No| D

    B -->|Custom business event<br/>not tied to a record| F

    B -->|External system<br/>publishes event| G{Into Salesforce?}
    G -->|Yes| F
    G -->|No| H[External event broker<br/>Kafka/RabbitMQ/SQS]

    D --> I{Subscriber?}
    F --> I
    I -->|External, high throughput| J[Pub/Sub API]
    I -->|External, moderate| K[CometD / REST]
    I -->|Salesforce internal| L[Apex Trigger / Flow]

    style D fill:#e3f2fd
    style F fill:#e8f5e9
    style H fill:#f3e5f5
    style J fill:#fff3e0
    style K fill:#fff3e0
    style L fill:#e8f5e9

9. Authentication Flow Selection

Choosing the right OAuth flow for each integration type.

flowchart TD
    A[Integration Authentication] --> B{Who initiates<br/>the connection?}

    B -->|External system calls SF| C{Involves a<br/>user context?}
    C -->|Yes, user-facing app| D[Web Server Flow<br/>Authorization Code]
    C -->|No, server-to-server| E{Need user context<br/>for data access?}
    E -->|Yes| F[JWT Bearer Flow<br/>with service user]
    E -->|No| G[Client Credentials Flow<br/>no user context]

    B -->|SF calls external system| H{Named Credentials<br/>available?}
    H -->|Yes| I[Named Credentials<br/>with appropriate auth]
    H -->|No| J[Custom Auth in Apex<br/>NOT recommended]

    style D fill:#e8f5e9
    style F fill:#e8f5e9
    style G fill:#e3f2fd
    style I fill:#e8f5e9
    style J fill:#ffcdd2

Quick Reference: Decision Summary Table

DecisionDefault AnswerOverride When
Sync vs AsyncAsync (safer, more scalable)User is blocked without immediate response
Middleware vs P2PP2P for < 4 systems4+ systems, complex transforms, governance needs
REST vs SOAPRESTLegacy WSDL requirement or Partner WSDL needed
ETL vs ELTETL (transform outside SF)Transformations are trivial or SF-native logic required
Which APIREST APIVolume > 2K (Bulk), events (Pub/Sub/CDC), multi-step (Composite)
TimingBatch (cheapest, simplest)Business requires fresher data
Error handlingRetry + DLQ + monitoringAdd circuit breaker for systemic failures
Auth flowJWT Bearer for S2S, Web Server for usersNo user context needed (Client Credentials)
EventsCDC for data changes, PE for business eventsCustom 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 Content

Sources