DataRaptors vs Integration Procedures: When to Use Which

When I first started building in OmniStudio, I had two tools that seemed to do similar things, and I kept reaching for whichever one I had used last. Sometimes my screens were slow. Sometimes my logic was scattered across five places. The problem was never the tools themselves. The problem was that I had not yet learned which job each one was built for.

So let me save you that confusion. DataRaptors and Integration Procedures are both about data, but they answer two different questions. Once you can name the question, the choice becomes easy.

DataRaptors: one clean data operation

A DataRaptor does a single, focused job with data. That is its whole personality. It reads, writes, or transforms, and it does so cleanly.

There are four types you will meet:

• DataRaptor Extract reads data from Salesforce and shapes it into JSON.
• DataRaptor Load writes incoming JSON back into Salesforce records.
• DataRaptor Transform reshapes JSON from one structure to another, no database involved.
• DataRaptor Turbo Extract is a faster, lighter Extract for simpler single-object reads.

Think of a DataRaptor as one verb. “Get the account.” “Save the contact.” “Reformat this JSON.” If you can describe the task in a single sentence with one action, a DataRaptor is very likely your tool.

Integration Procedures: the orchestrator

An Integration Procedure is server-side. Its job is to coordinate several steps in a sequence, running them on the server in one trip rather than making the browser do all the back-and-forth.

Inside an Integration Procedure you might:

1. Call a DataRaptor Extract to read an account.
2. Call an external REST API to fetch a credit score.
3. Run some conditional logic based on the response.
4. Call a DataRaptor Load to save the result.

That is four operations, glued together with logic, all happening in one server-side flow. No single DataRaptor can do that, and you would not want it to. A DataRaptor that tried to orchestrate would stop being clean and simple.

If the task is one action, reach for a DataRaptor. If the task is “do this, then this, then decide, then that,” reach for an Integration Procedure.

How they work together

Here is the part that ties it all together: Integration Procedures call DataRaptors. They are not rivals. The Integration Procedure is the conductor, and DataRaptors are the musicians who each play their one part well. In my old teaching days I learned that a good lesson is not one giant explanation; it is small, clear steps in the right order. OmniStudio rewards exactly that habit.

A typical, healthy pattern looks like this. Your FlexCard or OmniScript calls one Integration Procedure. That Integration Procedure calls the DataRaptors and APIs it needs. Your UI stays simple, your logic lives in one well-named place, and each DataRaptor remains reusable on its own.

A quick decision checklist

Ask yourself these questions:

• Is it a single read, write, or reshape? Use a DataRaptor.
• Do I need several steps in sequence? Use an Integration Procedure.
• Do I need conditional branching or error handling between steps? Integration Procedure.
• Am I calling an external system and combining it with Salesforce data? Integration Procedure, calling DataRaptors inside it.
• Will the browser otherwise make many separate calls? Move it server-side into an Integration Procedure.

That last point matters more than beginners expect. Every call your screen makes to the server costs time. If an OmniScript fires off six DataRaptors one after another from the browser, the user waits for six round trips. Wrap those in one Integration Procedure and the user waits for one. Performance is often won here, quietly, before anyone notices.

Avoid the common trap

The mistake I see most is over-orchestrating. A beginner reads “Integration Procedures are powerful” and builds one for everything, even a plain “load this single account name” step. Now there is a wrapper around a wrapper, and debugging takes twice as long.

Do not build an Integration Procedure for a job a single DataRaptor handles. Complexity is not a sign of skill. The cleanest solution that does the job is the skilled one. Start with the simplest tool that answers the question, and only climb to the orchestrator when the job genuinely has multiple steps.

If you keep that discipline, your OmniStudio work stays readable months later, which is a gift to whoever maintains it, often a future version of you.

Your next step

Now that you can tell these two tools apart, go deeper on each. Read DataRaptors to master single data operations, then study Integration Procedures to see orchestration in full. If you also work outside OmniStudio, Flow, Apex, or Clicks? sharpens the same “pick the right tool” instinct across Salesforce. And whenever you want the bigger picture, the OmniStudio hub ties it all together.