OmniStudio is a set of low-code tools that ships with Salesforce industry clouds. It builds guided forms, at-a-glance record cards and multi-step data calls. Its four parts are OmniScripts, FlexCards, Integration Procedures and Data Mappers. Financial Services Cloud, Health Cloud and other industry clouds use it for intake, onboarding and service journeys. It needs specialist skills, so it shapes both cost and partner choice.
What is OmniStudio, in plain terms?
It is a toolkit for building fast, guided user experiences on top of an industry cloud data model. Salesforce acquired it with Vlocity and now runs it natively on the platform.
Think of it as four building blocks that snap together. A screen collects input, a card shows a summary, and a server-side process fetches and saves the data. Many prebuilt industry processes, such as client discovery questionnaires or member intake, already arrive as OmniStudio components. Your team then adapts them rather than starting from scratch.
Current Salesforce documentation styles the names as Omnistudio, Omniscripts and Flexcards. You will see both spellings in proposals and older material, and they mean the same thing.
What do the four OmniStudio components actually do?
Two components face users and two work behind the scenes. Each has a closest standard Salesforce equivalent, which matters when you decide what to build.
- OmniScripts: step-by-step guided forms with branching, validation and save-for-later. A loan application or a patient referral form is typical.
- FlexCards: compact, clickable summaries of a customer, policy, account or case, often placed on a record page or console.
- Integration Procedures: server-side sequences that call several data sources, transform results and return one response, with optional caching.
- Data Mappers: declarative tools that read, transform, load or extract Salesforce data in JSON form. Before Spring '24 they were called DataRaptors.
The rename did not change underlying API names, so developers may still see “dataraptor” in metadata and URLs. That is expected and harmless.
What is the difference between the managed package and the standard runtime?
The managed package runtime is the original Vlocity-era version, installed as a package with its own custom objects. The standard runtime is built into the platform and stores components on standard Salesforce objects.
Salesforce has stated that, from Summer '25, OmniStudio is package-free for new customers. The designers and runtime come natively with supported cloud licenses. Its stated goal is to move every customer to the standard runtime over time. Salesforce reports faster execution on the standard runtime, though gains depend on how components are built.
If your org still runs the managed package, Salesforce provides the Omnistudio Migration Assistant to assess and convert components. It is not fully automatic. Custom Lightning web components, Apex actions called from components, custom functions and pages that embed components still need manual updates. Salesforce help also says the migration is unsupported for some setups, such as Data Mappers with multiple versions.
Which Salesforce licenses include OmniStudio?
Most industry clouds include OmniStudio, but the exact entitlement depends on your edition and contract. Confirm it in writing with your Salesforce account team before scoping any work.
Salesforce lists OmniStudio alongside Financial Services Cloud, Health Cloud, Manufacturing Cloud, Communications Cloud, Energy and Utilities Cloud and other industry products. Users also need the right permission set licenses to run or design components. Core Sales Cloud and Service Cloud licenses on their own do not usually include it. Packaging changes often, especially as industry clouds are rebranded and bundled with AI features, so verify rather than assume.
When should you use OmniStudio instead of Flow or Lightning web components?
Use OmniStudio when a journey is data-heavy, touches outside systems, or must match an industry template you already license. Use Flow for simpler internal processes your admins can own.
OmniScripts are design-first: they give finer control over layout, branding and multi-step navigation, which suits customer portals. Screen Flows are process-first: they handle record logic and approvals well, and more admins already know them. Integration Procedures shine when one screen needs data from several APIs in a single call. Lightning web components remain the right choice when you need behavior neither tool supports.
The worst outcome is a mix with no rule behind it. Pick a default per use case, write it down and review exceptions. Our guide on custom work versus configuration covers the wider trade-off.
| OmniStudio component | Closest standard tool | Choose OmniStudio when | Choose the standard tool when |
|---|---|---|---|
| OmniScript | Screen Flow | The form is branded, customer-facing, long or adapted from a licensed industry template | The process is internal, record-centric and owned by admins |
| FlexCard | Lightning record page components, Dynamic Forms or a custom LWC | Staff need a dense, actionable summary pulling from several objects or an external source | A standard related list, highlights panel or compact layout already answers the question |
| Integration Procedure | Autolaunched Flow with HTTP callouts, or Apex | One request must combine several sources with mapping, caching and error handling | A single, simple callout or record update is enough |
| Data Mapper | Flow Get and Update Records elements, or Apex | Data must be shaped into nested JSON for an OmniScript, FlexCard or outbound API | Plain record reads and writes are all that is needed |
What skills does OmniStudio work require?
It needs people who understand JSON data structures, APIs and the industry data model, not only point-and-click setup. That is why a capable general admin can still struggle with it.
OmniStudio is labeled low-code, yet its components pass JSON between them. Debugging means reading nested data, element names and merge fields. Integration Procedures call REST endpoints and Apex, so someone must understand authentication, timeouts and payloads. Salesforce offers a separate OmniStudio Developer and OmniStudio Consultant certification track. Its existence signals the gap between this work and standard administration.
- A designer who can map a business process into OmniScript steps and reusable sections.
- A builder comfortable with JSON, Data Mapper transforms and Integration Procedure debugging.
- A developer for custom Lightning web components, Apex hooks and deployment pipelines.
- An architect who knows where the industry data model ends and custom objects begin.
How does OmniStudio affect performance and maintainability?
Well-built components are fast, but careless ones become slow and hard to change. The risks are usually design choices rather than platform limits.
Performance problems tend to come from too many server calls per screen, large payloads and missing caching. Fetching whole records when a screen needs three fields is a frequent cause. Integration Procedures can batch calls and cache responses, which helps when used deliberately.
Maintainability depends on naming, versioning and reuse. Each component carries versions, and only one is active at a time. Without conventions, teams lose track of which version runs where. Deployment also needs care, because components and their dependencies must move together between sandboxes and production. Plan a source-controlled release process early.
How does OmniStudio change implementation cost and partner selection?
It adds scope in design, specialist build and testing, and it narrows the pool of suitable partners. Ask about it directly in every proposal.
Cost rises with the number of distinct journeys, the external systems each touches and how far you depart from the shipped templates. Testing grows too, because each branch of a guided form is a path someone must check. A migration from the managed package adds a further workstream if your org started on it.
When you compare partners, look past general industry cloud experience. Ask to see OmniStudio work they have delivered, and who on the team holds the related certifications. Ask how they decide between OmniStudio and Flow, and how they deploy and version components. A vague answer to any of these is a warning sign.
- Which journeys will you build in OmniStudio, and which in Flow or code, and why?
- Will you start from the licensed industry templates, and how far will you change them?
- Are we on the managed package or standard runtime, and does the plan include migrating?
- How will our team maintain these components after launch, and what training is included?
What mistakes do teams make with OmniStudio?
Most problems come from choosing the tool before the use case, or leaving support to chance. Each one is avoidable with early decisions.
- Rebuilding every screen in OmniScripts when a Screen Flow would have been simpler to own.
- Heavily customizing shipped templates, which makes future Salesforce updates harder to absorb.
- Starting new builds on the managed package runtime without checking what Salesforce now recommends.
- Skipping caching and payload trimming, then blaming the platform for slow screens.
- Leaving inactive component versions in place with no naming rules, so nobody knows what is live.
- Handing finished components to an admin team with no JSON or API background and no runbook.
For the industry-specific side of these projects, see our Financial Services Cloud and Health Cloud implementation guides. They cover data models, integrations and compliance that this article leaves aside.
