Integration - General
See also: Official References for the source Salesforce docs behind everything below.
How to approach an integration requirement
For each requirement, work through these steps - it keeps your talk track structured and surfaces hidden integrations.
| Step | Question to answer |
|---|---|
| 1. Event / Trigger | What starts it? Record create/update, button click, schedule, inbound call, external event. |
| 2. Handler | Who orchestrates it? Flow, Apex trigger, LWC, or middleware (ESB/ETL). |
| 3. Feature / Method | Which Salesforce capability? Apex callout, External Service, Platform Event, CDC, Salesforce Connect, REST/SOAP/Bulk/Pub-Sub. |
| 4. Pattern | Real-time, near-real-time, or batch? Sync vs async? |
| 5. Result | What happens in the end system? e.g. order synced to ERP. |
| 6. Response handling | Is a response needed, and does the user wait for it? |
| 7. Error handling | Retry (where?), notify the user, fail gracefully, fallback. |
Key rule: if the user must wait for the outcome to continue, the pattern must be synchronous; otherwise prefer asynchronous for resilience and scale.
List of Most Common Integration Patterns
| Pattern | Timing | Sync/Async | Description |
|---|---|---|---|
| Request & Reply | Real-time | Sync | Call and wait for the process to complete (user needs the result). |
| Fire & Forget | Real-time | Async | Call and don't wait for the process to complete. |
| Batch Data Synchronization | Batch | Async | Bulk move/sync of large data sets (Bulk API / ETL). |
| Remote Call-In | Real-time | Either | External system calls Salesforce to CRUD data. |
| Remote Process Invocation | Real-time | Either | Salesforce triggers a process in a remote system. |
| UI Update Based on Data Change | Near-real-time | Async | Subscribe to events/streams and refresh the UI. |
| Data Virtualization | Real-time | Sync | Salesforce Connect external object (OData) - no data stored. |
Integration methods (Salesforce features)
| Method | Direction | When to use |
|---|---|---|
| REST API | Inbound | Standard CRUD/queries; lightweight, JSON, mobile/web clients. |
| SOAP API | Inbound | Strongly-typed contracts; legacy/enterprise systems needing WSDL. |
| Bulk API 2.0 | Inbound | Large data volumes (LDV), data migration, batch loads. |
| Apex Callout (REST/SOAP) | Outbound | Custom outbound calls with transformation/logic. |
| External Services | Outbound | Declarative callouts from Flow using an OpenAPI spec - low code. |
| Outbound Message | Outbound | Legacy declarative SOAP message; no further Salesforce investment - prefer alternatives. |
| Platform Events | Both | Decoupled pub/sub, custom payload, fan-out to many subscribers. |
| Change Data Capture | Outbound | Stream record changes to keep an external system in sync. |
| Pub/Sub API | Both | Publish & subscribe to events efficiently (gRPC, binary). |
| Salesforce Connect | Both | View/CRUD external data live without storing it (OData / cross-org). |
| Canvas | UI | Embed a third-party app inside the Salesforce UI (good behind a firewall). |
| Streaming API (PushTopic) | Outbound | Subscribe to SOQL-based change notifications (legacy vs CDC). |
Technologies
- REST API
- SOAP API
- Streaming API (Events)
- Change Data Capture
- Platform Event
- Kafka (Apache)
- OData (Data Virtualization)
Middleware: ESB vs ETL
Prefer middleware over point-to-point to avoid tight coupling and to centralize governance, transformation, and reuse.
| ESB | ETL | |
|---|---|---|
| Purpose | Real-time system-to-system messaging & orchestration | Batch processing of large data sets |
| Style | Event/message bus, loose coupling | Extract -> Transform -> Load |
| Typical use | Sync data between CRM and ERP in real time | Data migration, bulk sync, load into a data warehouse |
| Example | MuleSoft Anypoint as a message bus | Scheduled bulk jobs, archiving to a warehouse |
Note: Salesforce can't participate in distributed (two-phase) transactions - the middleware layer owns queuing, buffering, retries, and orchestration.
Integration architectures
| Architecture | Idea | Trade-off |
|---|---|---|
| Point-to-point | Direct system-to-system links | Simple at first; brittle and unscalable as systems grow. |
| Hub & spoke | Central hub mediates connections | Fewer links; hub can become a bottleneck/single point. |
| ESB | Shared message bus with orchestration | Best for scale/governance; more setup and skills needed. |
Error handling
- Retry - where? Usually in the ESB/middleware, not in Salesforce.
- Notify - surface a clear error to the user when a synchronous call fails.
- Fail gracefully - handle predefined downtime windows; don't break the user flow.
- Fallback - give users a manual way to proceed/check status when the integration is down.
- Idempotency - design retries so reprocessing the same message is safe.
Security & authentication
- Use a dedicated integration user with an API Only profile (least privilege).
- Prefer External Client Apps for AuthN/AuthZ over legacy connected apps / SOAP login.
- Store credentials in Named Credentials (no secrets in code).
- Secure the message (TLS, encryption) and the network (e.g. Canvas for a system behind a firewall).
- One integration per user for the cleanest, most auditable setup.
Anti-patterns to avoid
- Swivel chair - manually rekeying data between systems (except rare edge cases).
- Unnecessary replication - if data doesn't need to live in Salesforce, virtualize it with Salesforce Connect (more data -> LDV -> performance/debt).
- Point-to-point sprawl - many direct links instead of middleware.
- Sync where async fits - blocking the user on a remote system you don't control.