Integration is where most enterprise programmes succeed or fail quietly. I've architected integration for multi-org healthcare platforms, headless commerce, public sector portals and a telecom landscape where Salesforce orchestrates quoting, ordering and customer systems. The lesson that repeats: choose the pattern before you choose the tool.
The patterns I reach for
| Pattern | Use when | Typical Salesforce mechanism |
|---|---|---|
| Request & reply | The user is waiting and needs the answer now (price, availability) | Apex callout, External Services, Named Credentials |
| Fire & forget | Something must happen elsewhere, but nobody waits for it | Platform Events, Outbound Messages, Queueable callouts |
| Event-driven / CDC | Other systems need to know when records change | Change Data Capture, Pub/Sub API |
| Batch data sync | Large volumes, latency in hours is fine | Bulk API 2.0, ETL / MuleSoft batch |
| Remote call-in | External systems create or update Salesforce data | REST / Composite API, Apex REST |
| Data virtualisation | Data must be visible but should not be copied | Salesforce Connect, Data 360 zero-copy |
API-led connectivity, in plain words
MuleSoft's API-led approach organises integrations into three layers. It sounds like overhead until you've maintained a landscape of point-to-point connections.
flowchart TB
subgraph EXP[Experience APIs · shaped for a consumer]
E1[Service console API]
E2[Partner portal API]
E3[Agent action API]
end
subgraph PRC[Process APIs · business logic & orchestration]
P1[Order-to-cash]
P2[Customer 360]
end
subgraph SYS[System APIs · unlock systems of record]
S1[(ERP)]
S2[(Billing)]
S3[(Order Mgmt)]
S4[(Salesforce)]
end
E1 & E3 --> P1
E2 --> P2
P1 --> S1 & S2 & S3
P2 --> S4 & S2
API-led connectivity — reuse grows as you move down the layers
- System APIs hide the quirks of each backend. Change a backend; only its System API changes.
- Process APIs hold the business orchestration — "create an order" across three systems.
- Experience APIs shape data for a specific consumer: a console, a portal, a mobile app — or an AI agent's action.
Field noteWith agentic AI, Experience APIs designed for agents are becoming a real category. Agents need small, well-described, single-purpose operations — exactly what a good Experience API provides.
Questions I ask before picking a pattern
- Is a user waiting? If yes, what's the acceptable latency?
- What's the volume — per hour, and at peak?
- Which system is the source of truth for each entity?
- What happens when the other side is down? (Retry, queue, fail gracefully?)
- Does the operation need to be idempotent? (Almost always: yes.)
- Who monitors it — and how will they know it failed?
Do
- Use Named Credentials for every outbound call
- Design for retries with idempotency keys
- Prefer events for change notification
- Centralise error handling and alerting
Don't
- Make synchronous callouts from triggers
- Let two systems both "own" the same field
- Build point-to-point when three consumers need the same data
- Ignore API limits until production
A good integration is one nobody notices. Design for the day something fails, and that's what you'll get.
Pranav Sanvatsarkar is a Solution Architect with 14+ years across telecom, healthcare, public sector and non-profit, focused on AI, agentic automation and Salesforce architecture. Say Hello!