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.