Salesforce integration patterns: ERP, marketing, support
A Salesforce integration is rarely hard because of the connection. It is hard because of what happens when the other system is slow, down, or disagrees about the data. Choosing the right pattern up front is what separates an integration that runs quietly for years from one that generates a support ticket every week.
Four patterns cover almost everything.
1. Request and reply
Salesforce calls another system and waits for the answer before continuing. A rep clicks to check live inventory or pull a credit decision, and the result appears on screen.
Use it when the user needs an answer immediately and cannot proceed without it. Be careful: it couples your user experience to someone else's uptime, so it needs a timeout, a clear message when the other side is unavailable, and a way for the user to continue without the answer if the process allows.
2. Fire and forget
Salesforce sends a message and moves on without waiting. An order is created and pushed downstream for fulfilment.
Use it when the receiving system does not need to answer and the user should not be blocked. The critical detail is delivery guarantees: if the message fails, something must retry it and something must eventually tell a human. Fire and forget quietly becomes fire and lose without that.
3. Batch synchronisation
Records are reconciled on a schedule, usually overnight. Product catalogues, price books, and customer master data typically move this way.
Use it for large volumes of slow-changing data where a few hours of staleness is acceptable. The failure mode to design for is the partial batch: what happens when three thousand of five thousand records load and the job dies. Batches need to be restartable and idempotent, meaning running the same batch twice does not create duplicates.
4. Event-driven
A change publishes an event, and any number of systems subscribe. Platform Events and Change Data Capture make this native to Salesforce.
Use it when several systems care about the same change, or when you want to decouple the producer from the consumers so that adding a fourth subscriber does not mean modifying the first three. It is the most flexible pattern and the one that most rewards having monitoring in place from day one.
Choosing per system
| System | Usual pattern | Why |
|---|---|---|
| ERP master data | Batch | High volume, slow-changing, staleness tolerable |
| ERP order and invoice status | Event or request and reply | Users act on it promptly |
| Marketing platform | Fire and forget or event | Volume is high, immediate confirmation is not needed |
| Support and telephony | Request and reply | The agent needs the answer during the call |
The decisions that actually determine success
Field ownership. For every synchronised field, one system is the source of truth. Writing this down before building prevents the update loops where two systems overwrite each other forever.
Idempotency. Every interface should tolerate being run twice. Networks retry, and integrations that assume exactly-once delivery create duplicates.
Visible failure. Errors must reach a person with enough context to act. An integration that fails silently is worse than one that fails loudly, because you find out from a customer.
Volume headroom. Test at several times current volume. Governor limits and API caps are discovered at the worst possible moment otherwise.
Integration work is where most Salesforce development projects either become reliable or become a maintenance burden, and it is usually the largest single line in a Salesforce implementation estimate for exactly that reason.
