From Vlocity to OmniStudio: what actually changed

If you search for help with OmniStudio, half of what you find still says Vlocity. If you inherit an older org, the component names, the package namespace, and the tribal knowledge all predate the rebrand. Understanding the lineage isn't nostalgia — it's practical archaeology, and it changes how you plan upgrades, hiring, and architecture.

The short history

Vlocity was founded in 2014 as an industry-cloud company building on top of the Salesforce platform — pre-built applications for communications, media, energy and utilities, insurance, health, and government, all powered by a common toolkit of guided flows, data mapping, and integration components. Salesforce announced its acquisition of Vlocity in early 2020, in a deal valued at roughly $1.3 billion, and closed it later that year.

Post-acquisition, Salesforce split the offering conceptually in two. The industry applications became Salesforce Industries — the vertical clouds. The underlying toolkit was rebranded OmniStudio and, importantly, was made available beyond the industry clouds. That second move is why OmniStudio now shows up in orgs that have nothing to do with telecom or insurance.

The renaming map

Most components kept their function and lost their prefix. If you're translating old documentation, forum posts, or a veteran colleague's vocabulary:

Vlocity era	OmniStudio era	What it does
Vlocity OmniScript	OmniScript	Guided, branching user flows
Vlocity Cards	FlexCards	Contextual 360° views and actions
Vlocity DataRaptor	DataRaptor (Omni data mapping)	Declarative extract / transform / load
Vlocity Integration Procedures	Integration Procedures	Server-side orchestration of data calls
Vlocity CPQ	Salesforce Industries CPQ	Catalog-driven configure-price-quote
Vlocity EPC	Enterprise Product Catalog	Shared product and pricing model

What actually changed

1. Packaging and runtime

The Vlocity toolkit shipped as a managed package with its own namespace and its own custom objects. Since the acquisition, Salesforce has been progressively moving OmniStudio toward running on core platform infrastructure — standard objects and metadata rather than package-namespace custom objects. If you run an older org, which runtime model you're on is one of the first questions that matters: it affects deployment tooling, upgrade paths, and how your components are stored.

2. Who uses it

Under Vlocity, the toolkit came bundled with an industry cloud. Under Salesforce, OmniStudio is licensable more broadly, which changed the buyer. Plenty of adopting teams today have no industry-cloud context at all — they bought OmniStudio for guided experiences or document generation, and they're encountering design patterns that were originally shaped by telecom-grade product catalogs.

3. The talent pool got weirder

Pre-acquisition, Vlocity skills were rare but coherent: people learned the whole stack because customers deployed the whole stack. Today the pool is split between Vlocity-era veterans who know why the patterns exist, and newer practitioners certified on OmniStudio in isolation. Both are valuable; they are not interchangeable, especially on CPQ and EPC work where the deep model knowledge is almost entirely Vlocity-era.

What didn't change

The architectural philosophy survived intact. OmniStudio is still fundamentally about a JSON-in, JSON-out pipeline: DataRaptors shape data, Integration Procedures orchestrate it, OmniScripts and FlexCards present it. Good Vlocity-era discipline — thin OmniScripts, reusable extraction layers, catalog-first CPQ modeling — is still exactly what good OmniStudio discipline looks like. The prefixes changed; the failure modes didn't.

Practical takeaway: when evaluating help, ask when they learned this stack. “Since the Vlocity days” answers a lot of questions in four words.