Salesforce integrations fail in predictable ways. The pattern you choose determines which failures you get and how easily you recover from them.
The four patterns
| Pattern | Use when | Main risk |
|---|---|---|
| Salesforce calls out, synchronously | A user is waiting for a response | External slowness blocks the user; callout limits |
| Salesforce calls out, asynchronously | Notify another system of a change | Silent failure if unmonitored |
| External system calls Salesforce | External system owns the trigger | API limits; needs authentication management |
| Scheduled batch both ways | Bulk sync, tolerant of delay | Data stale between runs |
Synchronous callouts from triggers are the pattern that causes most production incidents. A trigger that calls an external API blocks the transaction until it responds, consumes callout limits per record, and fails the entire save if the external system is slow. Almost always, the right answer is to queue the work asynchronously.
Choosing between them
- Does a user need the answer now? If not, do not make it synchronous.
- Which system knows when something changed? That system should initiate.
- What volume? High volume argues for batch; low volume tolerates event-driven.
- What delay is acceptable? Most businesses tolerate minutes comfortably.
- What happens if it fails? Design the recovery before the happy path.
Design the failure path first. Every integration will experience an outage on the other side; the ones that survive it are the ones that treated that as the normal case rather than the exception.
Salesforce-specific constraints to plan around
- Callout limits per transaction — a small number, which per-record callouts exhaust immediately.
- No callouts after DML in the same transaction without going asynchronous.
- Daily API request limits for inbound calls, tied to your edition and licences.
- Timeout ceilings on outbound calls.
- Governor limits apply to integration code exactly as they do to everything else.
What every integration needs regardless of pattern
| Component | Why |
|---|---|
| Idempotency | Retries and duplicate events happen |
| Retry with backoff | Transient failures are the common case |
| Dead-letter handling | Something must catch persistent failures |
| Structured logging | Diagnosis without it is guesswork |
| Alerting to a person | Logs nobody reads are not monitoring |
| Reconciliation | Proving the two systems agree |
| Credential rotation plan | Tokens expire, usually at a bad moment |
Platform Events are underused for outbound integration. Publishing an event from a trigger and processing it asynchronously decouples the save from the external call entirely — the user's save succeeds regardless of what the other system is doing, and the event can be retried independently.
Build, connector, or middleware
| Option | Suits | Breaks down when |
|---|---|---|
| Off-the-shelf connector | Standard systems, standard mapping | Requirements diverge from the standard |
| Direct custom integration | One or two connections, specific logic | Count grows; logic duplicates |
| Middleware platform | Several integrations, central monitoring | Cost and a platform to learn |
Start with a connector if one plausibly fits. Move to custom when it does not. Adopt middleware when the number of integrations makes central management worth its cost — not before, and not as an architectural principle.
Warning signs in an existing integration
- Callouts inside triggers, synchronously.
- No visibility into whether it ran successfully today.
- Failures discovered by users.
- No way to replay a failed message.
- Credentials stored somewhere other than named credentials or a secret store.
- Nobody can produce a reconciliation between the two systems.
Planning an integration, or repairing one that fails quietly? Tell us the systems and the volumes. See our Salesforce service, governor limits, and integration strategy.