Integration Procedure
An Integration Procedure (often abbreviated IP) is a declarative, server-side process in Salesforce OmniStudio that runs several actions in a single server call.
Definition
An Integration Procedure (often abbreviated IP) is a declarative, server-side process in Salesforce OmniStudio that runs several actions in a single server call. It reads, transforms, and writes data across Salesforce objects and external systems without requiring user interaction, and returns one structured JSON response. Think of it as the OmniStudio equivalent of a stored procedure: a reusable backend that other components call rather than each rebuilding the same logic.
Integration Procedures are part of the OmniStudio toolset alongside OmniScripts, FlexCards, and Data Mappers. An IP earns its place when a screen or process needs to bundle multiple operations together. A customer summary panel, for example, can call one Integration Procedure that queries Account, Contact, Service Contract, and open Cases at once, trims the result, and hands back a payload shaped for the front end. The same IP can be invoked from an OmniScript, a FlexCard, a Salesforce Flow, an Apex class, or an external REST call.
How Integration Procedures fit the OmniStudio architecture
Where IPs sit in the OmniStudio toolset
OmniStudio is the Salesforce Industries low-code suite, formerly sold as Vlocity. It bundles four declarative building blocks that work together. OmniScripts are guided, user-facing wizards that walk someone through a multi-step task. FlexCards are Lightning components that summarize a record or display actionable data tiles. Data Mappers (the tool earlier branded DataRaptor) move data between Salesforce and JSON, extracting or loading records based on a mapping you configure. Integration Procedures are the server-side layer that the other three lean on for heavy data work. The split matters because each tool has a clear job. OmniScripts and FlexCards live in the browser and handle presentation. When they need data fetched, combined, or written, they hand that work to an Integration Procedure instead of doing it client-side. The IP runs on the Salesforce server, calls Data Mappers and other actions, and returns a finished payload. This keeps the front-end components light and lets one backend serve many consumers. Build the logic once in an IP, then reuse it across every OmniScript and FlexCard that needs the same data.
The server-side, single-call execution model
The defining trait of an Integration Procedure is that it runs entirely server-side and bundles its work into one round-trip. A FlexCard or OmniScript makes a single call to the IP. The procedure then executes its full chain of actions on the server, assembles the response JSON, and returns it. The browser never sees the intermediate steps. Compare that to doing the same work client-side, where each query or callout would be its own request between the browser and Salesforce. Five separate lookups become five round-trips, each carrying network latency. An Integration Procedure collapses those five into one server-side sequence, so the client waits for a single response. Salesforce documentation calls out this performance gain directly: server-side processing removes browser-based delays, and a single server call prevents repeated client-server trips. The model also centralizes logic. Business rules live in the IP on the server, not scattered across front-end configurations where they are harder to audit and easy to duplicate.
Actions: the building blocks of the chain
An Integration Procedure is assembled from actions arranged in sequence, and each action sees the cumulative data that earlier actions produced. The common action types cover most data work. A Data Mapper Extract Action (or its Turbo variant) runs a Data Mapper to query Salesforce records. A Data Mapper Post or Load Action writes records back. An HTTP Action makes an outbound REST callout to an external API or website. A Remote Action calls an Apex method when you need code-level logic. Set Values writes computed or static values into the IP state so later actions can use them. A Response Action shapes what goes back to the caller, trimming unwanted nodes so the browser receives only what it needs. Salesforce describes this as removing unwanted data to slim the payload. Actions can also call another Integration Procedure, which lets you compose smaller IPs into larger flows. Because every action reads from and writes to one shared data structure, designing an IP is mostly about ordering actions correctly and naming their outputs so the next action can find them.
Blocks: conditions, loops, caching, and error handling
Actions rarely run in a flat list. Integration Procedures group them inside blocks that configure shared behavior. A Conditional Block runs its contained actions only when a data condition is met, which lets one IP branch for different inputs. A Loop Block repeats its actions over a list, processing each item in turn, useful when you need to call an API once per record in a collection. A Cache Block stores results so repeated runs skip the work, and a Try/Catch Block wraps actions in error handling so a failure can be caught rather than bubbling up to the caller. Salesforce documentation describes blocks as the way to configure conditional execution, caching, looping, and error handling for the actions they contain. Blocks can nest, so a Loop Block might contain a Conditional Block that contains the HTTP Action you actually want to run under specific conditions. Getting block structure right is most of the skill in building a non-trivial IP. A clean block layout reads top to bottom and makes the debug log easy to follow.
Caching, async, and the chainable setting
Integration Procedures support response caching to cut repeat load. You can cache an entire procedure response or an individual step for a configurable duration, then serve the cached result until it expires. Caching pays off most for frequently called IPs that return semi-static data, such as a product catalog, a configuration lookup, or reference values that change rarely. The tradeoff is staleness, so cache only what tolerates a delay before refresh. For heavier work, IPs can run synchronously or asynchronously, and they offer a chainable setting plus support for Apex Continuations. Chaining breaks a long IP into segments so each segment runs within Salesforce governor limits rather than blowing past them in one transaction. Apex Continuations let an IP make long-running external callouts without holding a synchronous thread. Salesforce documentation ties these features to avoiding governor limit violations during long-running operations. The practical rule: short, interactive IPs run synchronously, while batch-style or callout-heavy IPs lean on async, chaining, or continuations to stay inside limits.
Who calls an IP, and how you ship it
The reuse story is what makes Integration Procedures worth building. The same IP can be invoked from an OmniScript step, a FlexCard, a Salesforce Flow, an Apex class, a batch job, or an external system over REST. Salesforce documentation lists exactly these consumers. That portability means one well-built IP becomes shared backend infrastructure rather than logic locked to a single screen. Front-end and backend teams can even work in parallel, with the UI built against sample data while the IP is finished separately. Shipping IPs follows OmniStudio deployment practice. Every IP is versioned: saving creates a new version, and you must activate a version before components can call it, with older versions kept for rollback. Moving IPs between sandboxes and production historically used the Vlocity-supplied IDX Build Tool, and modern OmniStudio also supports standard Salesforce DX metadata deployment. Whichever path you use, the activation step is easy to forget. An OmniScript pointing at an inactive or missing IP version simply fails to return data, which is a common first-deployment surprise.
When to reach for Apex instead
Integration Procedures are declarative first, and that is both their strength and their ceiling. They shine for data orchestration: fetch from several sources, transform, write back, return a tidy payload. When the logic stays inside that shape, an IP is faster to build and easier for an admin to maintain than equivalent Apex. The action chain is visible, the debug log shows each step, and there is no class to compile or test class to write. Apex remains the right tool when logic exceeds what the action set expresses cleanly. Complex transactional batch processing, intricate state machines, or algorithms with deep branching become unreadable as long action chains and belong in code. Many Industries implementations mix both deliberately. IPs handle the record-summary fetches and standard read or write orchestration, while Apex handles the unusual business rules, called from the IP through a Remote Action when needed. The judgment call is honest: if you find yourself fighting the declarative model with dozens of Set Values and nested conditions, that logic probably wants to be Apex.
Build a simple Integration Procedure
You build an Integration Procedure in the OmniStudio designer by dragging actions into the structure panel, configuring each one, then previewing and activating a version. The steps below cover a common read pattern: fetch records with a Data Mapper, trim the response, and make the IP callable from an OmniScript.
- Create the Integration Procedure
In the OmniStudio app, open the Integration Procedures tab and create a new IP. Give it a Type and a SubType (together these form the unique name), since OmniScripts and FlexCards reference an IP by Type/SubType. Save to generate the first version.
- Add a Data Mapper Extract action
Drag a Data Mapper Extract (or Turbo) Action into the structure panel and name it descriptively, such as GetAccountDetails. In its properties, pick your Data Mapper in the interface field, then map the input identifier (for example AccountId) into both the data source and filter value so the query knows which record to pull.
- Shape the output with a Response Action
Add a Response Action and set its Send JSON Path to return only the nodes the caller needs. This trims the payload so the browser receives a clean, minimal structure instead of every field the Data Mapper produced.
- Preview and test
Open the Preview tab, enter sample input as key-value pairs, and select Execute. Read the debug log to confirm each action received the right input and produced the expected output. Fix any mapping mismatches before activating.
- Activate the version
In the procedure configuration, select Activate Version. Until a version is active, no component can call the IP. Activating also locks that version, so further edits create a new draft version.
- Call it from a component
In an OmniScript, add an Integration Procedure Action and point it at your IP by Type/SubType, passing the required inputs. The OmniScript now fetches its data through the IP in a single server call.
The two-part unique name of the IP. Components reference the procedure as Type_SubType, so choose names that read clearly and stay stable.
A setting that splits a long IP into segments, each running within governor limits, for batch-style or callout-heavy procedures that would otherwise exceed a single transaction.
Per-procedure or per-step caching that stores results for a set duration. Best for semi-static data like catalogs or configuration lookups.
On a Response Action, the path that selects which data nodes return to the caller, used to trim the payload to only what the front end needs.
- Forgetting to activate a version is the most common first-deployment failure. The IP exists, but every caller gets empty data until a version is activated.
- Action output names must match what later actions reference. A typo in a node name silently breaks the data passing down the chain, with no compile error to warn you.
- Pushing complex branching logic into nested Conditional and Set Values blocks produces an IP that is harder to debug than the Apex it is trying to avoid. Move heavy logic to a Remote Action.
- Caching semi-static data is great until the data changes and the cache still serves the old payload. Match cache duration to how often the source actually updates.
Prefer this walkthrough as its own page? How to Integration Procedure in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Integration Procedure.
Hands-on resources to go deeper on Integration Procedure.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is an Integration Procedure within Salesforce OmniStudio's declarative tooling?
Q2. What kinds of operations can a single Integration Procedure chain together at runtime?
Q3. How is an Integration Procedure exposed so external systems can call it directly?
Discussion
Loading discussion…