What are Integration Procedures?

Overview

Integration Procedures are declarative, server-side orchestration components in Salesforce OmniStudio (formerly Vlocity). They run multi-step integrations and data transformations without Apex, synchronously or asynchronously, and they are where I put logic that sits between Salesforce and an external system.

Why Integration Procedures matter

One procedure bundles HTTP calls, DataRaptor transformations, Apex actions and conditional logic into a single execution plan. That cuts the number of client-server round trips and keeps the orchestration in one reusable, testable unit instead of spread across components.

Key building blocks

The elements you will use most:

Start is the entry point for an execution.

Action covers the units of work:

HTTP Action calls external REST or SOAP services.

DataRaptor Extract/Transform/Load maps data declaratively between JSON or XML and Salesforce objects.

Integration Procedure Action calls a nested procedure, which is how you keep things modular.

Apex Action runs custom Apex when the declarative actions cannot do the job.

Set Variables / Assign stores intermediate values and transforms data inside the procedure.

Conditional (If/Else) branches on runtime data.

Execution modes

Synchronous returns a response to the caller straight away, which is what OmniScripts and FlexCards normally use. Asynchronous hands long-running work to platform events or scheduled jobs.

Typical use-cases

Common uses:

- Aggregating data from several systems into one JSON response for a UI component.

- Running dependent actions in sequence, where each step needs what the last one returned.

- Mapping data between API payloads and Salesforce objects with DataRaptors.

- Moving orchestration off the client so the front end waits on one call instead of several.

Sample Integration Procedure JSON (simplified)

{
  "type": "IntegrationProcedure",
  "steps": [
    { "type": "DataRaptorExtract", "name": "GetAccount", "input": { "accountId": "%accountId%" } },
    { "type": "HTTPAction", "name": "CallPricingAPI", "endpoint": "https://api.example.com/pricing", "method": "POST", "body": "%payload%" },
    { "type": "DataRaptorTransform", "name": "NormalizeResponse" },
    { "type": "SetVariables", "name": "PrepareOutput" }
  ]
}

Best practices

- Keep each procedure focused and modular, and nest procedures when you want reuse.

- Prefer declarative DataRaptors and HTTP Actions over Apex where you can. The declarative version is easier for whoever inherits it.

- Handle errors explicitly with try/catch patterns, error handlers and a clear response structure.

- Keep synchronous work short. If an operation takes too long, design it as an asynchronous flow instead.

Monitoring and debugging

OmniStudio logs, Salesforce debug logs and the built-in interactive execution trace let you inspect inputs, outputs and intermediate variables. Put retry and circuit-breaker patterns around unstable external services so one bad endpoint does not take the whole call down with it.

Conclusion

Integration Procedures centralise orchestration, cut client-server traffic and express multi-step logic declaratively. If you find yourself writing Apex to chain a few callouts and mappings together, this is usually the cheaper place for that logic to live.