Vlocity Guide | Salesforce Industries | SalesforceTutorial

What is Vlocity in Salesforce Industries?

Vlocity was acquired by Salesforce in 2020 and became a core part of the Salesforce Industries portfolio. The practical value is simple: instead of starting with a blank Salesforce data model, an implementation team can begin with packaged industry objects, guided processes, product catalog patterns, and integration components that match common enterprise use cases.

In a normal Sales Cloud or Service Cloud build, the project team may create custom objects for policies, subscriptions, service locations, plans, coverages, product attributes, tariffs, quotes, orders, or claims. A Salesforce Industries implementation often starts with managed objects and packaged metadata for those concepts. That can reduce design time, but it also means the architect must understand package dependencies, versioning, licensing, data model constraints, and the release path.

Use the term carefully in documentation. For a new design, write Salesforce Industries, OmniStudio, Industries CPQ, or the exact cloud name. For a legacy backlog, migration plan, or managed-package org, keep the Vlocity label when it matches installed package names, metadata types, or administrator screens.

Which Salesforce primary industry vertical uses Vlocity patterns?

The phrase salesforce primary industry vertical usually refers to the industry cloud or sector package that defines the data model and process layer for a Salesforce Industries implementation. Examples include communications, media, energy and utilities, insurance, health, public sector, financial services, manufacturing, automotive, education, and nonprofit use cases. The exact product set depends on licenses and the managed packages installed in the org.

The decision is not only a naming exercise. The selected vertical affects object model design, data migration, product catalog setup, guided selling, security review, integration contracts, and the skills needed on the delivery team.

Vlocity Salesforce naming in current projects

The keyword vlocity salesforce appears in many searches because teams use both names during transition work. In practice, a project plan should map the old and current terms. For example, a story labeled “Vlocity DataRaptor cleanup” may become “OmniStudio Data Mapper cleanup” in a newer org, while a managed-package org may still show DataRaptor labels in Setup and deployment tools.

Salesforce Vlocity versus a custom Salesforce build

Salesforce Vlocity makes sense when packaged industry behavior matches a large part of the business process. A custom build may still be better when the org has a narrow process, a small product catalog, or requirements that do not fit the industry data model. The architecture decision should compare package alignment, implementation speed, test complexity, reporting needs, and long-term release ownership.

How does the Vlocity architecture work?

A production architecture normally has four layers: the Salesforce platform layer, the industry data model, OmniStudio interaction components, and integration services. The industry package supplies objects and metadata. OmniStudio supplies guided screens and orchestration. Apex, Flow, and Lightning Web Components still have a place, but they should not replace packaged tools without a design reason.

Core building blocks

Where Apex still belongs

Apex belongs in a Vlocity project when the requirement needs transaction control, complex validation, callout handling, or logic that OmniStudio configuration cannot express safely. Use Apex as a service boundary, not as a place to hide business rules that should be visible to admins.

The following class is a safe pattern for an Apex action that can be invoked from automation. It bulk-processes requests, returns one response per input, and avoids SOQL inside loops. Adapt the object and fields to your licensed data model.

public with sharing class PolicyEligibilityAction {
    public class Request {
        @InvocableVariable(required=true)
        public Id accountId;

        @InvocableVariable(required=true)
        public Decimal annualPremium;
    }

    public class Response {
        @InvocableVariable
        public Id accountId;

        @InvocableVariable
        public Boolean eligible;

        @InvocableVariable
        public String reason;
    }

    @InvocableMethod(
        label='Evaluate Policy Eligibility'
        description='Returns an eligibility result for each account request.'
    )
    public static List<Response> evaluate(List<Request> requests) {
        List<Response> results = new List<Response>();
        if (requests == null || requests.isEmpty()) {
            return results;
        }

        Set<Id> accountIds = new Set<Id>();
        for (Request req : requests) {
            if (req != null && req.accountId != null) {
                accountIds.add(req.accountId);
            }
        }

        Map<Id, Account> accountsById = new Map<Id, Account>([
            SELECT Id, Name, IsActive__c
            FROM Account
            WHERE Id IN :accountIds
        ]);

        for (Request req : requests) {
            Response res = new Response();
            res.accountId = req == null ? null : req.accountId;

            Account acct = req == null ? null : accountsById.get(req.accountId);
            if (acct == null) {
                res.eligible = false;
                res.reason = 'Account was not found or is not accessible.';
            } else if (acct.IsActive__c != true) {
                res.eligible = false;
                res.reason = 'Account is not active.';
            } else if (req.annualPremium == null || req.annualPremium <= 0) {
                res.eligible = false;
                res.reason = 'Annual premium must be greater than zero.';
            } else {
                res.eligible = true;
                res.reason = 'Eligible for quote review.';
            }
            results.add(res);
        }

        return results;
    }
}

Governor limit note: the query runs once for the whole request, not once per item. In an enterprise org, also review CRUD and field-level security, the running user context, transaction size, package namespace, and permission requirements for Apex invoked from Integration Procedures.

How does OmniStudio support Salesforce Vlocity projects?

OmniStudio is the main configuration toolkit used in many Salesforce Industries implementations. Salesforce documentation describes OmniStudio standard designers as platform-native tools for OmniScripts, FlexCards, Data Mappers, and Integration Procedures. For teams coming from managed packages, this matters because older orgs may still have package-based runtime behavior while newer orgs may use standard designers directly on the platform.

OmniScript for guided processes

Use an OmniScript when the user must complete a guided process with screens, conditional branches, validation, and data submission. Examples include customer onboarding, plan selection, quote capture, policy changes, benefit enrollment, and service request intake. Keep each script narrow enough to test and version. Do not put every process branch into one script just because the business calls it one journey.

FlexCard for summary and action panels

A FlexCard should show context and launch actions. In a contact center console, a card might show a policy status, billing account, open claim, order status, or next action. It should not become a full application screen. If the card requires many unrelated data sources, split it or move the process into an OmniScript.

Data Mapper and DataRaptor for data shape control

Data Mapper is the current standard-designer term for the backend tool that handles extraction, loading, and transformation in OmniStudio. Many managed-package orgs and older project documents still use DataRaptor. In either case, the design principle is the same: return only the data the experience needs, map JSON names consistently, and document input and output samples for testing.

Integration Procedure for orchestration

Use Integration Procedures for server-side orchestration, especially when an OmniScript or FlexCard needs to combine Salesforce data, decision logic, and external service calls. They help avoid repeated client-side requests and provide a reusable service layer for multiple UI components.

Official references: Salesforce Help: OmniStudio, Salesforce Developers: OmniStudio standard designers, and Trailhead: Get Started with OmniStudio on the Salesforce Platform.

How does Vlocity Insurance work?

Vlocity insurance usually refers to Salesforce Industries Insurance managed-package capabilities and related Financial Services Cloud insurance features. Typical objects and processes include policies, coverages, claims, insured parties, benefits, quote-to-bind flows, service transactions, document generation, and integrations with policy administration or claims systems.

Vlocity insurance data model considerations

Start by identifying the system of record for each insurance concept. Salesforce may be the engagement layer while a core policy system owns policy issuance, endorsements, billing, and claims adjudication. Do not duplicate source-of-truth logic in Salesforce unless the business has decided that Salesforce owns that domain.

For a policy service console, a practical design might use a FlexCard to summarize the policy, an OmniScript to submit a policy change, a Data Mapper to write request data, and an Integration Procedure to call the policy administration API. If the API returns a pending status, store a transaction record and show the status to the service agent rather than blocking the user until the external system finishes.

Common insurance implementation checks

• Policy identity: decide whether the external policy number or Salesforce record Id drives user search, integration matching, and duplicate prevention.
• Coverage model: verify whether coverages, riders, benefits, and insured assets map cleanly to packaged objects.
• Claims visibility: enforce role-based access so an agent sees only the claim data they need.
• Documents: define which templates are generated in Salesforce and which documents come from a policy or claims platform.
• Audit trail: capture request payloads, response status, and user action history for regulated service processes.

Review the current Salesforce Help pages for Insurance managed packages and the Industries Insurance and Financial Services data model before finalizing object design.

Is Vlocity CPQ the same as Industries CPQ?

In current Salesforce documentation, the product is generally described as Industries CPQ, while many teams still say Vlocity CPQ. It is not the same thing as standard Salesforce Quotes or every Revenue Cloud implementation. Industries CPQ is designed for complex industry products, bundles, attributes, pricing, promotions, and order capture in supported Salesforce Industries contexts.

Enterprise Product Catalog, usually shortened to EPC, is the catalog foundation. It stores the product structure, attributes, cardinality, compatibility rules, and commercial relationships that the quoting experience depends on. A bad catalog design causes quote errors later, so catalog governance should start before the first migration load.

When Industries CPQ is a fit

• The product has nested bundles, configurable attributes, eligibility rules, or promotions.
• Quote capture must align with order decomposition or fulfillment systems.
• The business operates in communications, media, energy, utilities, insurance, or another supported industry pattern.
• The quote process needs guided selling rather than a simple quote line editor.

When a simpler quote model may be enough

A smaller team with fixed products, no bundling, and limited pricing rules may not need Industries CPQ. In that case, standard Salesforce products and price books, Salesforce CPQ, Revenue Cloud, or a lightweight custom process may be easier to maintain. The right answer depends on license scope, product complexity, integration needs, and administrator skill set.

Official references: Salesforce Help: Enterprise Product Catalog and Salesforce Help: Industries Configure, Price, Quote.

How to implement Vlocity in an enterprise org

A Vlocity implementation needs more upfront architecture than a small Sales Cloud configuration project. The package gives you starting assets, but those assets still need design, naming, testing, release control, and operational ownership.

1. Confirm the installed product and runtime

Start with licenses, installed packages, namespace behavior, and runtime type. Existing customers may have managed packages; newer orgs may use OmniStudio standard designers. Document the exact setup because deployment, troubleshooting, and permissions differ by runtime.

2. Map business capabilities to packaged assets

Create a capability map before building screens. For each process, record the packaged object, OmniStudio component, integration endpoint, security owner, and reporting requirement. This prevents a common failure: building custom objects because the team did not know an industry object already existed.

3. Design the integration contract

Most industry projects depend on billing, policy, claims, rating, provisioning, fulfillment, document, or ERP systems. Define request and response JSON early. Use Integration Procedures for reusable orchestration and keep the UI independent from external API quirks.

4. Build with version control and deployable artifacts

Track Salesforce metadata, OmniStudio components, permission sets, named credentials, remote site settings where required, custom metadata, and test data setup. In a managed-package org, confirm the supported deployment toolchain for OmniStudio datapacks and package metadata before selecting the release process.

5. Test with production-shaped data

Unit tests are not enough. Run end-to-end tests with realistic product catalogs, eligibility rules, account hierarchies, policy records, quote sizes, permission sets, and external service failures. Include negative tests for timeouts, partial responses, duplicate policy numbers, expired catalog versions, and users without required access.

6. Train admins on what not to customize

Admins need a support model that explains which assets are safe to configure, which need architecture review, and which should not be changed because package upgrades or integrations depend on them. In enterprise orgs, uncontrolled catalog edits and cloned OmniScripts often create defects that are hard to trace.

Best practices for Vlocity Salesforce delivery

Keep OmniStudio components small and named consistently

Use naming that includes domain, process, type, and version intent. For example, use names such as INS_PolicyChange_Address_OS for an OmniScript and INS_PolicySummary_FC for a FlexCard. A consistent naming pattern makes search, deployment review, and defect triage easier.

Prefer server-side orchestration for shared logic

If two screens need the same data preparation, place the logic in an Integration Procedure or service layer instead of duplicating it in two OmniScripts. This reduces mismatched behavior across channels.

Design security before screen configuration

Salesforce security still applies: object permissions, field-level security, record sharing, permission sets, and Apex class access affect what users can see and run. Do not assume a packaged component bypasses the security model. Test with least-privilege users, not only with System Administrator profiles.

Use Apex only when it earns its place

Apex adds compile-time safety and transaction control, but it also adds test maintenance, governor limits, and deployment risk. Before writing code, check whether an Integration Procedure, Data Mapper, Flow, validation rule, or packaged configuration can handle the requirement with clearer ownership.

Plan for package and release changes

Salesforce Industries receives product updates through Salesforce releases and package updates. Keep a regression suite for critical OmniScripts, FlexCards, CPQ catalog flows, quote calculations, and integration procedures. Read the current release notes before activating new runtime behavior or migrating from managed-package designers to standard designers.

Document fallback behavior

Industry processes often depend on external systems. Define what the user sees when rating, policy, billing, or claims services fail. A good design returns a useful status, saves the transaction for retry, and avoids losing the user input.

Common errors with Vlocity projects

Related SalesforceTutorial resources

• OmniStudio tutorial for Salesforce Industries projects
• Salesforce CPQ configuration and quote process guide
• Lightning Web Components guide for Salesforce developers
• Salesforce Data Cloud architecture and use cases

Frequently Asked Questions