Remote process invocation
Salesforce's integration patterns are a catalogue of proven ways to connect systems, and an architect chooses among them by the requirements — timing, volume, coupling, and error handling. This lesson covers Remote Process Invocation (RPI), the family of patterns where one system triggers a process in another and, usually, waits for a reply. It is the right choice when an action in one system must cause, and often confirm, an action in another in near-real time.
RPI comes in two shapes. Request-Reply is synchronous: Salesforce calls an external service and blocks until it gets a response — for example, submitting an order to an ERP and receiving back an order number to store. Fire-and-Forget is asynchronous: Salesforce notifies the external system but does not wait, suitable when confirmation is not needed immediately.
The mechanics on the Salesforce side are Apex REST/SOAP callouts (secured with named credentials), and the platform imposes rules an architect must design around. Callouts cannot follow DML in the same transaction, and a synchronous callout cannot be made from a trigger — so real-time RPI triggered by a data change is implemented with an asynchronous Queueable or with a Platform Event that a subscriber acts on. For fire-and-forget from a data change, publishing a platform event or enqueuing async work is the clean approach.
Request-Reply (synchronous):
Salesforce --callout--> External service
<--response-- (order id, status) [waits, stores result]
Fire-and-Forget (asynchronous):
Salesforce --notify--> External service [does not wait]
(via Platform Event or Queueable callout)Design considerations dominate here. Timeouts and retries: synchronous callouts must be fast and handle failure gracefully, so architects cap timeouts and define retry/compensation logic. Idempotency: because retries and duplicate messages happen, the receiving process should tolerate the same request twice without double-effect. User experience: never block a user-facing save on a slow external call — push it async and update the record when the reply arrives.
As an exercise, take "creating an Opportunity must reserve inventory in an external ERP and store the reservation id" and decide: synchronous or async, callout from where, and how to handle a timeout. The next lesson covers the opposite end of the spectrum — moving large volumes of data on a schedule.
