What Is Salesforce Vlocity and Which Industries Actually Need It?

Salesforce Vlocity is the industry software Salesforce acquired in 2020 and folded into Salesforce Industries. It gave complex sectors like communications and insurance ready-made data models and transaction tools built around how those businesses already work.

The name still causes confusion in 2026. Many live orgs still run Vlocity packages and namespaces, while Salesforce now sells the same ideas under newer product names. The Salesforce acquisition announcement lists the original sectors: communications, media and entertainment, energy and utilities, insurance, health, and government.

Whether you need it depends on the business process. A small reseller with a fixed catalog can run well on standard Salesforce. A national communications provider may manage thousands of product combinations, with location rules and fulfillment steps spread across several systems.

Existing customers have a separate question to answer. Their org may hold managed packages or custom code tied to an older data model, so they need to review what’s already in place before any Salesforce Vlocity implementation begins.

TL;DR

Salesforce bought Vlocity in 2020 and moved much of its technology into Salesforce Industries. That’s why the name still shows up in package names and project language. The stack centers on Omnistudio, Enterprise Product Catalog (EPC), Industries CPQ, asset-based ordering and industry order management.

These tools earn their place when a company sells complex products and runs transactions across several systems. Communications, insurance, and energy and utilities have the clearest fit. Media, health insurance and parts of the public sector follow.

Process complexity decides the need, so start with an assessment of the current org. New buyers should also know that Salesforce now points them to package-free Omnistudio and Agentforce Revenue Management.

What does Vlocity in Salesforce mean?

Vlocity in Salesforce means the industry technology Salesforce gained through the Vlocity acquisition. The original company built industry data models, guided processes, catalog tools and quoting functions for sectors where general CRM records needed major additions.

Salesforce still keeps that older material in its own Help system. The Salesforce Industries Vlocity documentation index shows where it now lives. That’s one reason the name stays common in technical work, even after Salesforce renamed the products.

The term can point to different things in different orgs. It may mean a managed package, Industries CPQ, an older Omnistudio setup or custom code tied to Vlocity objects. Salesforce Industries is the wider current portfolio, and Omnistudio is the toolset for guided experiences and data interaction.

Find the exact product behind the label before making any design choice. Check the package version, runtime, namespaces and custom dependencies. Together they tell you whether the project is new work or a migration.

How Vlocity became part of Salesforce Industries

Vlocity existed because several industries kept solving the same Salesforce problems. Standard Salesforce models customers, opportunities, cases, products and orders well. Subscription-heavy and regulated industries need many more relationships.

A communications provider may need subscriptions, service locations, product offers and technical orders. An insurer needs policies, coverages, claims and producer relationships. Building all of that from custom objects and code adds a large design burden.

Vlocity supplied industry models and process components for these repeated patterns. Salesforce bought the company for about $1.33 billion in 2020 and folded much of that work into its industry portfolio. The value shows when the packaged model matches the business, so the team doesn’t have to build every relationship itself.

An early assessment should decide which industry concepts belong in Salesforce and which stay in existing business systems. It should also show where standard Salesforce already does the job well.

Today’s portfolio covers more sectors than Vlocity ever did. Automotive, manufacturing, retail and education products shouldn’t be described as former Vlocity products. This matters because 2 companies in the same sector can have very different starting points. A company with a long-running Vlocity package needs dependency analysis, while a company starting fresh on standard objects has more freedom to choose.

How the architecture works

The base layer is the industry data model. Standard Salesforce uses objects like Account, Contact, Opportunity, Case, Product and Order. Industry products add records that match how a sector works.

A communications company can link a customer to subscriptions, service addresses, assets and orders. A utility can connect customers to premises, service points, contracts and pricing. The data model gives each process its business context before any user flow or integration is built.

Omnistudio usually provides the guided experience on top of those records. Omniscripts run step-by-step processes, and Flexcards show context and available actions. Data Mappers read and write data, while Integration Procedures handle server-side work and system calls.

Salesforce’s Omnistudio standard-runtime migration guide calls the standard runtime the future direction for these components. Older orgs may still use the DataRaptor name and package-based objects, so inspect the org before assuming which design is in place.

Take a broadband plan change. An agent opens the customer’s account and current services, then checks whether a new offer is available at the service address. Eligibility and pricing rules apply before the customer confirms, and billing or network systems may need to respond before the request completes.

A single user action can touch several records and system calls. That’s why Omnistudio work should follow the business transaction from start to finish.

System ownership is part of the same architecture. Salesforce may own service interactions while billing runs on another platform, and policy status in insurance often belongs to a policy administration system. Every connection needs a named owner and a plan for when it fails. Map those boundaries before building screens, because moving data ownership later creates duplicate records and hard support issues.

Where EPC, Industries CPQ and order management fit

Enterprise Product Catalog (EPC) manages products with many commercial and technical parts. A broadband offer may include speed, equipment, installation, contract term and promotional pricing, each with rules that change by customer type. A simple product list gets hard to maintain as those combinations grow. EPC gives the business a central product structure that feeds quoting and ordering.

Industries CPQ uses that structure for configuration, pricing, quoting and order capture. It checks whether an offer is available and whether the customer is eligible, including against assets they already own. These checks matter most in subscription businesses, where most transactions change an existing service.

When CPQ or order work needs billing or inventory systems to respond mid-transaction, the integration design has to sit beside the product model. Advayan’s Salesforce integration services cover this layer. A quote is only useful when downstream systems can fulfill what was sold.

The quote-to-fulfillment path usually runs in this order:

1.       The product catalog defines the offer and its parts.

2.       Eligibility and compatibility rules decide what the customer can buy.

3.       Configuration and pricing create a valid commercial choice.

4.       The quote records what was agreed.

5.       Order capture creates the commercial order.

6.       Order management breaks the order into work for downstream systems.

7.       Billing, activation, inventory or field operations complete fulfillment.

Asset-based ordering handles changes to existing services. A customer may move service, add a feature, change a plan or disconnect a product, and communications teams group these actions under MACD. The process starts from the customer’s current assets, so each new order stays tied to the real service state.

New projects should also check Salesforce’s current revenue product. Salesforce’s revenue product guide positions Revenue Management, now sold as Agentforce Revenue Management, as the current platform product. It describes Industries CPQ as the managed-package product that came from Vlocity. Existing Industries CPQ customers may have good reasons to stay put for now, and a new buyer should compare both first.

Which industries need it?

The clearest cases appear where standard CRM objects don’t represent the operating model.

Communications and telecommunications

Communications has the clearest case for the industry stack. Providers may sell mobile, broadband, equipment, add-ons and contract terms inside a single customer relationship. Availability can depend on the service address, and price can depend on customer type or existing products.

The case gets stronger when an order crosses several systems. Salesforce may hold the customer, quote and commercial order, while billing, network activation and field installation run elsewhere. The Salesforce Communications Cloud documentation lists Industries CPQ, asset-based ordering, MACD and order management as core capabilities.

Test catalog size, product rules, serviceability and fulfillment. If they’re mostly simple, standard Salesforce may be enough. If they’re central to daily work, the industry stack earns its cost, and Omnistudio can guide users through complex steps without exposing every back-end system.

Insurance

Insurance fits well because the core business runs on records that outlive a sales opportunity. Policies, coverages, producers, renewals and claims form a long customer relationship. Rating and claims often run on platforms separate from policy administration, and Salesforce becomes the engagement layer on top.

Industry data models represent these relationships without rebuilding every concept. Omnistudio can guide a customer or agent through quoting, enrollment, policy service or claims intake. The main design question is which system owns policy status and claims data, and that decision should come before any screens or interfaces.

Check which data model the org already uses, because older package objects differ from newer implementations. New customers should note that Salesforce Help says not to install Vlocity Insurance on a new org. Start with current Salesforce insurance products instead.

Energy and utilities

Energy and utilities tie customer records to physical service. A customer links to a premise, and a premise can hold 1 or more service points. The provider manages offers, contracts, rates and service activity around those points.

A typical process starts with a premise lookup, then finds the service point and available offer. Pricing and eligibility rules apply before the contract is created, and the request may then send work to billing or operations. The Salesforce Energy and Utilities data model includes premises, service points, offers and contracts, so it’s a useful benchmark against the company’s current design.

If those concepts sit at the center of the business, the packaged model can cut custom work. An energy consultancy selling a short list of professional services is a weak fit, and Sales Cloud with Service Cloud usually covers it.

Media

Media businesses often run several commercial models. Subscription companies manage plans and contract changes. Advertising businesses manage inventory and rate agreements, and a large media group may run both in the same Salesforce estate.

The industry stack helps when product and contract relationships outgrow standard records. Guided processes support sellers and service teams, and industry data models cut repeated custom design. Any custom Apex or Lightning work should close a real gap and never duplicate a function the chosen industry product already supplies.

Treat a streaming business and an advertising network as separate cases. They often have different data owners and fulfillment paths, so map the commercial model first and pick components after.

Health insurance and payers

Health is a broad label, so scope it carefully. Vlocity’s history is strongest in payer and health-insurance processes. A payer may manage plans, benefits, enrollment, member records, claims and provider links, while a small physician practice may have none of that.

Omnistudio helps when enrollment or member service needs many questions and system checks. A guided flow leads the user through the process while Integration Procedures pull data from plan, provider or claims systems. Document which records Salesforce owns and which it reads from outside platforms before building.

Salesforce still publishes the Vlocity Health data model, which helps teams assessing older health implementations. Many existing customers are really facing a migration decision. The best health cases combine detailed plan relationships with long guided work across several connected systems.

Public sector

Public sector agencies have used Vlocity models for social programs, benefits, housing and case work. Many of these implementations have run package objects and custom components in production for years, so the upgrade path is a major part of planning.

Salesforce Help tells new customers not to install the Vlocity Government package. Agencies already on it need an inventory of how forms, automation, integrations and reports depend on its objects before any change begins. Advayan’s Salesforce maintenance and support services cover keeping that environment stable while the migration is tested and planned.

A new public sector project should start with current products like Public Sector Solutions and standard data models. That avoids launching a new program on a package Salesforce no longer recommends.

Does your company need it?

Process complexity is the best test, and this scorecard makes it concrete.

The more strong signals the business shows, the better the case. Also check whether the packaged model matches the real work. A poor fit can create as much support work as a custom build, especially when the team uses only a small part of the package.

Existing customers need to ask what’s already tied to the package. Code, integrations, reports and automation can depend on older objects, so the assessment should cover the revenue path alongside the data model.

The assessment should end in a written recommendation that sets the boundary for design and build. It should answer these questions:

1.       Which industry records are essential? List the records the business can’t run without, such as policies, service points, subscriptions or claims. Mark where each lives today and where it should live after the project.

2.       Which rules change the transaction? Record rules that affect eligibility, price, compatibility or contract terms. Assign each rule to Salesforce or the system that should own it.

3.       Which systems must respond during the process? Identify billing, policy, inventory, BSS, OSS or payment systems that take part. For each call, define the expected response and what happens when that system is down.

4.       Which existing components create dependency risk? Older orgs may hold managed-package objects or automation built on Vlocity structures. Separate active dependencies from components that no longer serve a process.

5.       What’s the future-state path? State what stays in place and what moves or retires. Account for the current runtime and product direction so a short-term fix doesn’t create another migration later.

If the assessment can’t answer these, the build isn’t ready to start. It should also record what’s out of scope, so unrelated process problems don’t get pulled into the project.

When standard Salesforce may be enough

Standard Salesforce handles many industry projects without an extra package. Sales Cloud, Service Cloud, Flow, standard objects and APIs cover a wide range of needs. If a company sells a short list of fixed services at simple prices, standard objects like Account, Product and Order may already represent it well. Adding an industry package there creates support work without solving a modeling problem.

Custom development suits unusual processes that don’t fit the packaged model. Compare the custom work each path needs and who’ll support it after launch. A package cuts repeated design but brings specialist skills and migration dependencies. A custom model gives more control, and the company then owns every design decision and its upkeep.

Pick the design that stays as simple as the business allows. Use the industry stack where it replaces real industry-specific work, and let a proper discovery phase keep users and admins from carrying technology they don’t need.

What changed in 2025 and 2026?

Salesforce is moving Omnistudio off the managed-package runtime. From Summer ’25, Omnistudio is package-free for new customers with supported cloud licenses. Existing Vlocity Industries package customers need a migration path instead.

The standard runtime uses the standard data model, so component migration can include data-model work. Salesforce also warns against uninstalling the package, because existing workflows and custom components may still rely on its schema.

The Omnistudio Migration Assistant helps move Omniscripts, Flexcards, Data Mappers and Integration Procedures. Salesforce recommends starting in a development sandbox and moving through validation before production, so treat the move as a controlled migration with full regression testing. The Omnistudio migration guidance sets out the transition path for each package type.

The revenue product has moved too. Industries CPQ still runs many existing industry environments, and Salesforce now directs new revenue development to Agentforce Revenue Management. A greenfield project should compare both, while existing customers weigh migration cost against staying on their current stack for now.

Older orgs keep running. Document the future-state path before adding major new development, or today’s fix will make tomorrow’s migration larger.

Existing customer vs new 2026 project

Existing customers and new buyers need different plans. An established org may hold years of Vlocity objects, configuration, code and integration logic that users rely on daily. Discovery comes first. Document package versions, namespaces, the data model, Omnistudio runtime, CPQ, EPC, order management, custom code and integrations.

A new project has more freedom. It can compare standard Salesforce with current industry clouds before choosing architecture. It can also start on the standard Omnistudio runtime and review Agentforce Revenue Management when revenue work is in scope.

Installing a legacy package because older projects did is a mistake. Let product direction and the real process drive the decision.

How to plan the implementation

A reliable Salesforce Vlocity implementation follows the business transaction from start to finish. Plan it in this order:

1.       Inventory the current org. Record packages, licenses, namespaces, data models, CPQ, EPC, Omnistudio runtime, custom code and integrations. Existing customers should also document release methods and any automation tied to package objects.

2.       Map the business process. Follow the real customer or employee journey, including each decision and system call. Record exception paths so the team knows what happens when data is missing or a system fails.

3.       Assign system ownership. Decide which platform owns customer, billing, policy, inventory, price and other main records. State what Salesforce stores and what it reads from other systems.

4.       Fit the industry model. Use packaged records where they match the process, and extend the model only for a real gap. Don’t create duplicate objects for concepts the package already handles.

5.       Design guided work and integrations. Use Omnistudio where users need conditional steps or several system calls. Add middleware such as MuleSoft when the project needs an integration layer across many business systems.

6.       Test the full transaction. Check price, eligibility, permissions, asset changes, system failures and data writes. Migration tests should also cover namespace and package dependencies.

7.       Define ownership after launch. Assign owners for product data, integrations, release testing and future platform changes, so support work doesn’t become an unplanned task.

Choose the simplest integration pattern that can handle the required systems and volume.

What should you look for in an implementation partner?

Start with the exact industry process. A communications quote-to-order project needs different experience from an insurance service project. Ask which industry cloud the proposed team has delivered and which part of the transaction it owned, then ask how it handles runtime and data-model changes.

The people assigned to the project matter more than company-level credentials. CPQ and EPC work needs product-model depth, while migrations need package and regression-testing experience. A good partner will also tell you when the industry stack is unnecessary.

Salesforce’s Partner Finder helps build a shortlist. Give direct references and named team members more weight than a general services page.

Getting help with a Vlocity project

Advayan’s Salesforce Vlocity services cover architecture, data models, Omnistudio, integration and ongoing support. If you’re weighing a new build or a migration, start with a current-state assessment of your org.

Conclusion

Salesforce Vlocity still matters because many live orgs run its packages and several industry products grew from it. The case is strongest when a company sells complex products through transactions that cross several connected systems. Standard Salesforce is the better choice when those conditions are absent.

Existing package customers also need a clear migration view as Salesforce moves Omnistudio to the standard runtime. Start with the business process and the current org, then choose the product path.

Frequently asked questions

Is Salesforce Vlocity still used in 2026?

Yes. The name still appears in existing packages, namespaces, documentation and implementation projects. Salesforce acquired Vlocity in 2020 and moved much of its technology into its industry products. Existing customers may still depend on Vlocity objects and managed packages, while new projects use current platform products.

Is Vlocity the same as Salesforce Industries?

They’re closely related. Salesforce Industries is the wider portfolio, and Vlocity is the part that came from the 2020 acquisition. Many current industry clouds were built by Salesforce and have no Vlocity origin.

What is Salesforce Omnistudio?

Omnistudio is Salesforce’s toolset for guided processes and data interaction. Omniscripts run step-by-step journeys, Flexcards show context and actions, Data Mappers read and write data, and Integration Procedures handle server-side work and system calls.

Is Omnistudio part of Vlocity?

Omnistudio came from Vlocity and was widely used with Vlocity Industries managed packages. Since Summer ’25, it’s package-free for new customers with supported licenses. Existing customers should check their runtime and package dependencies before planning migration.

What is Vlocity CPQ?

Vlocity CPQ is the older name for Industries CPQ. It handles product configuration, pricing, quoting, eligibility and order capture for industry use cases, and it works with EPC and asset-based ordering. New projects should compare it with Agentforce Revenue Management first.

Which industries use Salesforce Vlocity most?

Communications, insurance, energy and utilities, media, health insurance, and the public sector have the clearest Vlocity history. The real need depends on product complexity and how many systems a transaction crosses.

Does every company in those industries need Vlocity?

No. A business with simple products and fixed prices is often better served by standard Salesforce. The industry stack makes sense when it removes a real amount of custom industry design.

Can Vlocity connect with existing business systems?

Yes. Salesforce connects with billing, ERP, policy, inventory and claims systems through APIs or middleware, and Integration Procedures can call those systems inside guided processes. Define which system owns each record and what happens when a connected system is unavailable.

How do I choose a Salesforce Vlocity implementation partner?

Check experience with your exact industry cloud and business process. Ask who’ll do the work and how the partner will support the org after launch. A good partner will also tell you when standard Salesforce is enough.