Imagine sending a runner to the storeroom for one item, then sending them again for the next, and again for the third. Three trips for three things. Now imagine handing them one list and getting everything back in a single trip. That is the difference an Integration Procedure makes in OmniStudio. It is the last of the four pillars, and the one that quietly keeps your experiences fast.
What an Integration Procedure is
An Integration Procedure, often shortened to IP, is a server-side, action-based sequence of steps that runs together in one server call. Where a DataRaptor does a single piece of data work, an Integration Procedure orchestrates several pieces: read this, then call that external system, then transform the result, then return it all at once.
“Action-based” means you build it from a list of steps, each performing one action. “Server-side” means the whole thing executes on Salesforce’s servers rather than in the browser. That second point is the heart of why IPs matter, so let me explain it plainly.
Why round-trips matter
Every time a screen in the browser asks the server for something, that request travels out and the answer travels back. One round-trip. It is fast, but it is not free, and the cost adds up.
Suppose a FlexCard needs data from three different sources to render. If the card made three separate calls, that is three round-trips, each adding delay. Instead, the card can call one Integration Procedure. The IP gathers all three sources on the server, in a single visit, and returns one combined result. Three trips become one.
An Integration Procedure earns its keep by doing many things in one server visit, so the browser waits once instead of many times.
This is the practical reason IPs exist. They consolidate work, reduce the chatter between browser and server, and keep guided experiences feeling quick even when the data behind them is complex.
What lives inside an IP
An Integration Procedure is a sequence of steps, and the common ones are easy to recognize:
- DataRaptor Extract / Load actions to read and write Salesforce data.
- HTTP and REST actions to call external systems and services.
- Response actions to assemble and return the final result.
- Conditional and loop steps to branch or repeat logic.
- Set Values and formula steps to shape data along the way.
Each step can use the output of earlier steps. So step two can act on what step one fetched, and the response step can return a clean bundle built from all of them. It is orchestration: many small actions arranged into one coherent operation.
DataRaptors and Integration Procedures together
It helps to see where the line falls. A DataRaptor is for a single, focused data task: one read, one write, one transform. An Integration Procedure is for coordinating several of those, plus external calls, into one server-side flow.
So you do not choose one instead of the other. You use DataRaptors as the building blocks and an Integration Procedure as the conductor that arranges them. If you want a careful side-by-side of when to reach for each, I lay it out in DataRaptors vs Integration Procedures. The short version: simple data job, use a DataRaptor; multi-step orchestration, use an IP.
Where the integration part comes in
The name is honest. Integration Procedures are often where OmniStudio talks to the outside world. An IP can call a REST API to pull data from a billing system, combine it with Salesforce data, and hand the merged result back to a FlexCard or OmniScript, all in one call.
If web services are new to you, the broader concepts of calling and consuming APIs are worth grounding first. Salesforce Integration for Beginners covers that foundation gently. With those ideas in place, the HTTP actions inside an IP stop looking mysterious and start looking like ordinary steps.
Building one without fear
As always, I build in small phrases. Start an IP with a single DataRaptor Extract step and a response step that returns its output. Run it and confirm you get data back. Then add a second step that uses the first step’s result. Then add an external call. Each addition is verifiable, so when something breaks you know exactly which step to look at.
That patience pays off. Once you can chain three steps confidently, you can chain ten. And when you do, you will feel the quiet satisfaction of replacing a clutter of browser calls with one clean, efficient trip to the server, which is exactly what an Integration Procedure was made for.
Your next step
Continue with the data tools an IP orchestrates: