A working catalogue of Salesforce integration patterns

Pattern catalogues tend to be written from the optimistic end. Each entry explains what the pattern is for and where it shines, and the reader finishes the page able to name seven patterns and unable to eliminate any of them.

The elimination is the work. On a real interface three or four patterns will technically function, and the design decision is which of them stops being viable once volume, availability and reporting requirements are applied to it. So each entry below carries five things: what the pattern assumes about the system on the other side, how it behaves as volume rises, the consistency guarantee it does and does not give, the failure most likely to occur and who notices it first, and the single condition that rules it out.

The case for settling this before anyone opens a vendor comparison is made separately, in pick the integration pattern before you pick the middleware. This is the reference you use once that argument is won.

#The properties that decide fit

What it assumes about the far side. Every pattern makes a demand of the system at the other end: that it is available at the moment of the call, that it will accept a burst without shedding, that it can be queried interactively, that it can push rather than needing to be polled. Patterns fail most often because that assumption was never written down, so nobody checked it against a system the integration team does not own and cannot change.

How it behaves as volume rises. The question is not whether the pattern handles today's traffic. It is the shape of the failure when traffic triples: does the interface slow evenly, does it queue, or does it meet a boundary and stop. Confirm the specific governor and API limits that apply in the current Salesforce developer documentation, because they differ by API and by licence, and they change.

What consistency it gives. Nearly all of these are eventually consistent. What separates them is whether the convergence window is bounded and knowable, and whether anything at all detects a record that never converged.

The characteristic failure, and who notices first. This decides the support model more than any monitoring tool does. A failure a user sees is expensive and self-reporting. A failure only a month-end reconciliation sees has been running for weeks by the time it surfaces.

The condition that rules it out. One clause. When it is true, the discussion ends.

#Request and reply

Salesforce issues a callout and waits. Usually a person is waiting with it.

Assumes the far side is available now and responds inside a window a human will tolerate. That is a strong assumption to make of a system with its own release calendar and its own definition of a maintenance window.

Under volume it degrades badly rather than gracefully, because concurrent waiting transactions hold finite platform resources while they wait. Latency at the far side becomes contention on this side, which is why a slow partner presents as a Salesforce performance incident.

Consistency is the strongest available: the caller knows the outcome before continuing. That is the whole reason to pay the costs above.

Failure is immediate and visible. The user meets an error in a save path, support hears within minutes, and the escalation lands on the Salesforce team regardless of which system actually failed.

Ruled out when the interface sits in a save path that must complete during the far side's maintenance window, or when the far side offers no availability commitment you can point at.

#Fire and forget

Salesforce sends and continues. The user's work completes whatever happens next.

Assumes the far side will eventually accept the message, and that no decision on this side depends on the answer. It also assumes somebody owns the destination, which is less obvious than it sounds when the receiving team was not in the design workshop.

Under volume it is well behaved, because nothing is waiting. The pressure moves to the receiving system and to whatever holds messages in between.

Consistency is eventual with an unbounded window. Salesforce knows the message was sent. It has no knowledge of whether it was understood.

Failure is silent, and that property matters more than any other in this entry. Nobody notices at the moment of failure. Discovery arrives weeks later from somebody in the receiving business unit who says their system has been missing records since a date nobody can establish.

Ruled out when the receiving process is financially or legally material and no independent reconciliation exists that would detect a gap. Silent loss against a ledger is not an integration, it is an unrecorded liability.

#Batch data synchronisation

Scheduled bulk movement, typically overnight, typically large.

Assumes the far side can produce or accept an extract inside one window, and that the business genuinely tolerates the delay. The second assumption is the one that quietly stops being true, usually because a downstream team built something interactive on data that arrives once a day.

Under volume it is the most predictable pattern in the catalogue and the one with the hardest ceiling. Runtime grows with the data, the window does not, and the two lines cross on a date you could forecast if anybody watched runtime as a trend.

Consistency is bounded and knowable, which is genuinely valuable: at any moment you can state exactly how stale the data is.

Failure is noticed by an operations team the following morning, and it is recoverable. The dangerous variant is the partial success, where the job completes with a subset rejected and reports itself green.

Ruled out when any consumer needs the data inside the batch window, or when the source cannot reliably say what changed and the only option is to move everything every night.

#Publish and subscribe

The source publishes, interested consumers subscribe. On the platform this is Platform Events for messages you define, and Change Data Capture for record-level changes you did not have to model.

Assumes consumers can subscribe and keep up, and that they accept arrival order and duplication as their problem rather than the platform's. It also assumes the consumer list will change, which is the reason to choose it: the producer should not need to know who is listening.

Under volume it holds well, with one caveat that decides most incidents. A slow consumer falls behind rather than pushing back, and a consumer that falls far enough behind loses the ability to catch up at all, because replay windows are bounded. Confirm current retention behaviour in Salesforce documentation rather than assuming it.

Consistency is eventual, and the window is bounded only while every subscriber is healthy. One stopped subscriber converts an eventual guarantee into an indefinite one.

Failure is noticed by nobody, because the producer succeeded. Unless somebody monitors subscriber position rather than publish success, the first symptom is a business user reporting that two downstream systems disagree.

The two variants commit you to different things. A Platform Event is a contract you designed, so it survives a change to the underlying objects. Change Data Capture mirrors the data model, so it delivers completeness and hands every subscriber a coupling to your schema.

Ruled out when exactly one consumer exists, will only ever exist, and needs the data immediately. The decoupling has no value there, and it has been paid for in debugging difficulty.

#Remote call-in

An external system initiates and Salesforce responds, through REST, SOAP or a bulk job.

Assumes the caller behaves. That it will respect the shape of the interface, will not loop, and will not treat the org as an unmetered resource. None of that is true by default, and none of it stays under your control once credentials are issued.

Under volume the risk is not the interface, it is the shared allowance. Platform capacity for inbound API traffic is bounded across the whole org, so one poorly written caller degrades every other integration and, past a point, the org itself. This is the only pattern here whose failure mode is other people's interfaces.

Consistency is whatever the caller implements. You are the receiving side of somebody else's design.

Failure is noticed first by unrelated teams, which is what makes it distinctive to diagnose. The symptom appears in interfaces that have nothing to do with the caller that caused it.

Ruled out when the calling system cannot be given its own identity and its own bounded permissions, because a shared integration user makes attribution impossible on the day it matters. The engineering practice for these interfaces is covered in Salesforce API integrations that survive contact with production.

#UI update based on data changes

A record changes in the background and an open screen updates without the user acting.

Assumes the user is present, watching, and cares about the change within seconds. It is a presentation pattern layered on one of the others, and it moves no data of its own, which is why it is routinely absent from design and then requested during user acceptance testing.

Under volume the constraint is the number of concurrent sessions holding subscriptions, not the number of records changing.

Consistency is display level only. A screen refreshing is not evidence that any downstream system agrees with it.

Failure is noticed instantly by the user, and is almost always reported as the data being wrong rather than the screen being stale.

Ruled out when the underlying data movement is not already near real time. Live-updating a screen fed by a nightly batch produces a display that is confidently current and several hours old.

#Data virtualisation

Do not copy the data. Read it in place, with external objects presenting remote records alongside local ones.

Assumes the remote system can serve interactive queries under user-driven load at acceptable latency. That assumption is rarely tested against a system sized for nightly extraction rather than for people clicking.

Under volume performance belongs entirely to the remote system, and it is felt as page load time. Concurrency multiplies through user sessions rather than through record counts.

Consistency is exact and needs no reconciliation, because there is one copy. This is the strongest argument for the pattern and it is consistently undervalued: nothing synchronised means nothing to diverge, nothing to reconcile and no ownership dispute to settle later.

Failure is total and immediate for that data, and the user notices. The remote system being unavailable means the records are simply absent, which is a different experience from stale.

Ruled out when the data must be reported on jointly with local records at speed, or edited in Salesforce with platform behaviour external objects do not carry. Where the requirement is genuinely joint analysis across many sources, the answer is a consolidation programme rather than a pattern, and it brings its own prior decisions: see getting Data 360 right the first time.

#The catalogue

#A selection path that runs on properties

Preference is not an input. Four questions about the interface eliminate most of that table, and they are best asked in this order.

Does the caller need an answer before it can continue? If a decision on this side genuinely depends on the response, you are in request and reply and the rest of the catalogue is unavailable to you. Be strict about the word genuinely. Most requirements phrased this way are a wish to avoid designing what happens when the answer arrives a moment later.

Can the far side be unavailable without breaking the caller? If not, you have accepted that your availability is now bounded by theirs, and that deserves to be a written decision with a name against it rather than an accident of implementation. If it can, everything asynchronous stays on the table and the most expensive coupling in the catalogue has been removed.

Does this data need to be stored in Salesforce at all? The question is skipped almost universally and it carries the largest payoff. Storage creates a synchronisation obligation, a reconciliation obligation and an ownership argument, all of them permanent. If the data is read occasionally and never edited here, virtualisation removes all three at once.

How much divergence between the two systems is tolerable, and for how long? Answer in units the business recognises: an hour of stale pricing, a day of stale addresses, none at all on entitlement. This is what separates batch from publish and subscribe, and it is the answer most likely to stop being true without anybody revisiting it.

#Several patterns is the correct outcome

An estate that has settled on one pattern has either an unusually uniform set of interfaces or an architecture group that mistook consistency for design. Interfaces differ on exactly the properties this catalogue measures, so a mature estate carries five or six patterns at once, and that spread is evidence the choices were made rather than inherited.

What should be standardised is everything around the pattern rather than the pattern itself: how each interface is monitored, how a failure is detected and by whom, where the ownership record lives, and what the naming and logging conventions are. Standardise those and running six patterns costs little more than running one. Standardise the pattern instead and you spend years forcing interfaces into a shape that does not fit them, which produces exactly the workarounds that make an estate hard to reason about later.