DataRaptor
DataRaptor is OmniStudio's declarative tool for reading from, transforming, and writing to Salesforce data without writing Apex.
Definition
DataRaptor is OmniStudio's declarative tool for reading from, transforming, and writing to Salesforce data without writing Apex. You configure source fields, output structure, formulas, and validation in a guided UI, and the resulting DataRaptor becomes a reusable component that Integration Procedures, OmniScripts, FlexCards, and direct API callers can invoke. The four flavors (Extract, Transform, Load, and Turbo Extract) cover the common shapes of a CRUD operation.
Starting with Summer '24, Salesforce is renaming DataRaptors to Data Mapper inside OmniStudio (Data Mapper Extract, Transform, Load, and Turbo Extract). The capability is the same, the metadata is the same, and existing references keep working. New documentation and the OmniStudio Designer use the new name, while the underlying API objects still carry the legacy VlocityDataRaptor names for backward compatibility.
How DataRaptors work inside an OmniStudio org
The four DataRaptor types and when to use each
DataRaptor Extract reads from one or more Salesforce objects, follows lookup and master-detail relationships, and returns a shaped JSON or XML payload. DataRaptor Transform takes input JSON and reshapes it without hitting the database, useful for converting between two payload formats. DataRaptor Load writes a JSON payload into one or more Salesforce objects, including upsert by External Id. DataRaptor Turbo Extract reads one object at a time with field-level mapping only, skipping the heavier transformation engine; it is the fast path for high-volume read patterns.
The two-pane mapping UI
Inside the DataRaptor Designer, the left pane defines the source (object and SOQL filters for Extract, JSON path for Transform and Load). The right pane defines the output structure. Each row maps a source path to an output path with optional formulas. You can build nested objects, repeating groups, and conditional fields without writing code. Preview runs the mapper with sample data and shows the resulting payload inline.
Formulas, conditions, and the formula language
DataRaptor formulas support arithmetic, string concatenation, case statements, date math, and a curated set of functions. The formula language is similar to Salesforce formula fields but not identical: some functions exist only in DataRaptor, and others have different argument orders. Conditions on each mapping let you include or exclude rows based on the input, which is how you build branching outputs without splitting the DataRaptor.
Single-record versus bulk patterns
DataRaptor Load handles either one record or a list, depending on how the input JSON is structured. A list of accounts under accounts[] writes one row per element, with each element's properties mapping to fields. Single-record loads use a flat object. Combine the two by using a parent record with a nested list of children: the load happens in one transaction, parent first, then children with the parent's Id as their lookup.
Integration with OmniScripts, Integration Procedures, and FlexCards
DataRaptors are rarely invoked on their own. They sit inside Integration Procedures (multi-step server-side workflows) and OmniScripts (multi-step user-facing flows), and they back the data nodes of FlexCards (read-only cards on record pages). The same DataRaptor can serve all three, which is why you make them small and reusable: one Extract per object payload, one Load per write operation, named consistently.
Caching, governor limits, and performance
DataRaptor Extract supports response caching with a configurable TTL, which dramatically reduces SOQL load for read-heavy patterns. Without caching, each invocation issues fresh SOQL and counts against governor limits like any Apex query. Turbo Extract is the lowest-overhead read: it skips the full transformation engine and is the right choice when you need one object's fields with no joining or shaping. Profile in System Logs before assuming a DataRaptor is fast enough at production scale.
The Summer ''24 rename and migration path
OmniStudio Summer '24 introduced the Data Mapper name across the Designer UI and new documentation. The underlying metadata, API objects (VlocityDataRaptor__c, VlocityDataRaptorItem__c), and existing references in Integration Procedures and OmniScripts continue to work unchanged. There is no required migration. If you script DataRaptor deployment through the Metadata API or VBT, your existing tooling keeps working. Treat the rename as a documentation update, not a breaking change.
How to build a DataRaptor Extract (or Data Mapper Extract)
A DataRaptor Extract pulls Salesforce data into a JSON shape. The Designer walks you through the source object, the relationship traversal, and the output mapping; the result is a callable mapper that any OmniStudio element can invoke.
- Open the DataRaptor Designer
OmniStudio app, then DataRaptors tab (now labeled Data Mappers in Summer '24 orgs and later), then New. Pick Extract as the interface type.
- Name and configure the source
Give the DataRaptor a clear name (Account_GetWithContacts is better than Test1). On the Extract tab, pick the primary object and add any SOQL filters in the Extract Filter Definition.
- Define the output structure
On the Output tab, map source fields to output paths. Nest output paths with dot notation (Account.Owner.Name) and create lists with array notation (Account.Contacts[]). The Designer's preview pane shows the shape as you build.
- Add formulas and conditions
Use the Formula column for derived fields and the Conditions column to include or exclude rows. Functions like CONCAT, IF, and DATEVALUE behave like Salesforce formula fields with minor argument differences.
- Set caching if appropriate
On the Options tab, enable Cache Response and pick a TTL. Use this for reference data and read-heavy patterns; skip it for anything user-personal or rapidly changing.
- Save and test
Click Save, then use the Preview tab to invoke the DataRaptor with sample input. The response panel shows the shaped output and timing. Once it looks right, the DataRaptor is callable from any Integration Procedure or OmniScript.
Reads from Salesforce objects with full transformation. The default for read patterns that need joining or shaping.
Pure transformation on input JSON, no database access. Used to convert between payload formats.
Writes a JSON payload to one or more objects, with upsert by External Id supported.
Fast read of one object at a time, field-level mapping only, no formulas. The right choice for high-volume reads with simple shapes.
- DataRaptor Turbo Extract does not support formulas, conditions, or relationship traversal. If you need any of those, drop back to a regular Extract.
- Response caching is keyed on the input parameters. A DataRaptor with no input parameters caches one response for all callers, which is rarely what you want.
- DataRaptor Load runs as a single DML batch. Hitting the 10,000-record DML limit fails the whole load, not just the offending rows. Split very large loads across multiple invocations.
- The Summer '24 rename to Data Mapper does not affect existing references. You can keep using DataRaptor in conversation and in custom code without breaking anything.
Trust & references
Straight from the source - Salesforce's reference material on DataRaptor.
- DataRaptors OverviewSalesforce Help
- Design a Data MapperSalesforce Help
- DataRaptor ReferenceSalesforce Developers
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 DataRaptor?
Q2. What are the main DataRaptor types?
Q3. Why use DataRaptor instead of Apex for OmniStudio data operations?
Discussion
Loading discussion…