Who to hire for Vlocity on Salesforce

Most organisations looking for a Vlocity partner are not starting a project. They inherited one. A telecommunications, insurance or utilities business bought Vlocity before Salesforce acquired it, the logic now lives in a managed package that few people on the team fully understand, and someone senior has asked who can look after it. That is a different hiring problem from "find an implementation partner", and it deserves a different set of questions.

#What you are actually hiring for

Salesforce completed its acquisition of Vlocity in 2020, and the product line now sits under the Salesforce Industries banner. A sentence in a Gearset guide to rebrands puts the outcome plainly: "Vlocity, acquired in 2020, became Salesforce Industries (or Industries Cloud) providing deep, industry-specific solutions." The name on your invoice may have changed, but the artefacts in your org have not: OmniScripts that guide a call-centre agent through a plan change, FlexCards that surface an account at a glance, Integration Procedures that call billing and provisioning systems, and Data Mappers that move data in and out of Salesforce objects.

Those four components are the core of the skill set. Salesforce's own certification trail for the developer exam puts the working instruction this way: "Use the standard designer for Flexcards, Omniscripts, Integration Procedures, and Data Mappers in the standard runtime." Read that sentence twice, because it contains the most important hiring distinction on this page. The word runtime is doing real work. Some orgs run those components from a managed package, with its own namespace and its own data model. Others have moved to the standard runtime, where the same components are native to the platform. A partner who cannot tell you which one you are on after an hour with your org is not ready to look after it.

The package namespace is the quickest tell. Orgs on the older model carry prefixes such as vlocity_cmt or vlocity_ins on objects and fields, depending on the industry edition. Custom code, reports and integrations often reference those names directly, which is exactly why uninstalling the package is never a casual step. Salesforce's developer blog describes a command-line Omnistudio Migration Assistant that assesses an org and then migrates components to the standard data model, and the same posts warn that existing workflows and custom components may still rely on the package schema. You can read the current guidance on the Salesforce Developers blog. The point for a buyer is simple: a migration is a decision with a risk register, and a partner should be able to talk through that register before they quote.

#The skills and certifications that matter

Start with the credentials Salesforce actually issues. The Salesforce Certified Omnistudio Developer exam covers the build tools named above, and the Omnistudio Consultant credential is aimed at the person who translates a business process into a design. Salesforce also asks holders to complete maintenance modules each release cycle, so a certificate with no recent maintenance is a mild warning sign. Beyond those two, you want Platform Developer I for anyone writing Apex or Lightning Web Components around the OmniStudio layer, and the Industries consultant credential that matches your sector, whether that is communications, insurance, health or public sector. Check the current list on Salesforce's certification site rather than trusting a partner's slide.

Certifications prove vocabulary. They do not prove judgement. The skills that separate a safe pair of hands from a risky one are practical ones:

• reading an Integration Procedure that has grown over five years and finding the step that is slow
• knowing when a Data Mapper is the right tool and when it has been stretched into business logic
• understanding product catalogue and quoting behaviour if you use Industries CPQ or order management
• debugging OmniScript failures in a sandbox that does not mirror production data
• handling deployment of OmniStudio components, which behave differently from ordinary metadata

Ask for a short walkthrough of one real OmniScript from their past work, with client details removed. A person who built it will describe the awkward parts first.

#What a partner really does on this product

The day-to-day work is narrower than an implementation brochure suggests. A partner typically spends its time on five things. It builds or changes guided processes, for example a new quote journey or a revised claim intake. It maintains the integrations that those processes call, which means keeping Integration Procedures in step with changes to billing, policy or network systems. It looks after performance, because a procedure that calls three slow back-end services will make an agent's screen crawl whatever the platform does. It manages releases, since Salesforce ships three times a year and an OmniStudio component can behave differently after an upgrade. And it carries the knowledge, writing down why a rule exists so that a new joiner does not delete it.

The industry matters more here than on almost any other product. A communications provider's order capture, with its product catalogue, bundles and service qualification, has little in common with an insurer's quote and bind flow, even though both are built from the same four components. A partner whose references sit in a different sector can still be a good hire, but they should say so and show how they will learn your domain.

#A realistic first engagement

The best first engagement is an assessment with a written output. Two or three weeks is a sensible shape for a mid-sized org, though the real determinant is how many components exist and how well they are documented. The deliverable should include an inventory of every OmniScript, FlexCard, Integration Procedure and Data Mapper, a map of which external systems each one calls, a list of custom code and reports that reference the package namespace, and a candid view on whether staying on the managed package, moving to the standard runtime, or doing a staged hybrid makes sense for you.

Scope it so the partner cannot quietly turn the assessment into a build. Say in the request that no components will be changed, that production access is read-only, and that the output is a document you could hand to a different firm. If the assessment is good, the next piece of work writes itself and you can compare it with another quote. If it is poor, you have lost a few weeks rather than a year.

Do not accept a proposal that begins with "We will rebuild your Vlocity solution on the standard model". That sentence presupposes the answer. Some components may be fine where they are, some may be dead, and some may be the reason a major process still works.

#Release discipline and knowledge transfer

Two practical matters decide whether a partner relationship stays healthy after the first project. The first is release discipline. Salesforce releases three times a year, OmniStudio components have their own version history, and a change to a shared Integration Procedure can alter several screens at once. Ask how the partner tests regression across the guided processes that matter most, who signs off, and how they roll back a component that misbehaves on a Friday afternoon. A good answer mentions a named set of test scenarios, a sandbox that resembles production, and a habit of deploying small changes.

The second is knowledge transfer. Because so much of the logic sits in configuration rather than code, a departing consultant can take the understanding with them. Insist on documentation that explains intent, such as why a procedure calls a service twice or why a card hides a field for one customer type. Ask for a recorded walkthrough of the main journeys. Treat the documentation as a deliverable with a reviewer on your side, because nobody writes it well unless somebody reads it.

#Red flags specific to OmniStudio

Treating it like a generic CRM project is the classic failure. OmniStudio components are tightly bound to an industry process and to the systems behind it. Watch for these signs.

A partner who talks only about objects and fields and never about Integration Procedures has probably not worked on the product. A partner who proposes to uninstall the managed package early, before the dependencies are mapped, is courting an outage. A partner who says the old and new runtimes are interchangeable has not read the migration guidance. A partner who quotes a fixed price for a migration before seeing the org is guessing, and someone will pay for the guess.

Another quiet red flag is a team made up entirely of generalist administrators. Industries work needs developers who can read JSON structures and debug server-side calls, and at least one person who understands your sector. Insurance quoting and telecommunications order capture are not the same problem, and a partner whose references are all in a different industry should say so openly.

#Ten questions worth asking

Listen for specifics. A strong answer to the namespace question names how they would search the metadata. A strong answer to the migration question includes a case where the answer is no. A weak answer to the performance question blames the platform, while a strong one starts with the back-end call that is slow.

#Checking evidence without relying on logos

A logo wall tells you that someone at a firm once worked near a famous client. Ask instead for a named reference on a comparable industry process, and ask the reference three things: who from the partner actually did the work, what broke after go-live, and how the partner behaved when it did. Ask to see sanitised documentation from a past engagement, such as an inventory or a handover note. Check whether named consultants hold current Omnistudio credentials through Salesforce's public credential verification, and ask to speak to the person who will lead your work rather than the person who sells it.

#Commercial models and the statement of work

Assessments suit a fixed fee because the scope is bounded. Build and migration work is better as time and materials with a capped phase, or as fixed phases each with acceptance criteria, because the unknowns are real. Whatever the model, put these items in the statement of work: the runtime and namespace as found at the start, named roles with the certifications each holds, the environments in scope, the acceptance tests, the rollback plan for any production change, documentation you will own at the end, and a clause that no managed package is uninstalled without written agreement from you. For the money side of the work, see Vlocity implementation cost and the Vlocity licence page.

#When you can skip a partner

A partner is not always needed. If your org has a handful of OmniScripts, no managed-package dependencies that matter, and an employee who holds the Omnistudio Developer credential, hiring one contractor for a bounded task is likely enough. The same goes for a trivial change such as updating a label or an endpoint. Bring in a firm when the logic is business-critical, when the original builders have left, or when you are weighing a runtime migration, because that decision is expensive to reverse. Before you go to market, read what happened to Vlocity, should I migrate from Vlocity and integrating Vlocity with Salesforce, so that your brief reflects your real situation. This page ranks no agency and recommends none.