Important to note: From January 2023, users will need a Salesforce Industries add-on license to deploy Vlocity or OmniStudio components. Please, check our Pricing page for licensing details.
Just like any other changes made to Salesforce, Vlocity customizations should be developed and released as part of your DevOps workflow. That means changes need to be made in a developer environment first, tested properly and deployed along a release pipeline to production.
There's a key difference between Vlocity and most other Salesforce customizations: Vlocity configuration is described with data, not metadata. For this reason Vlocity data packs cannot be deployed using Salesforce's Metadata API or change sets.
Salesforce provides two tools specifically for Vlocity deployments. Vlocity Build can be used for running deployments from the CLI, while Vlocity's IDX Workbench is a UI-based tool. The downside of using either Vlocity Build or IDX Workbench is that you now have two separate deployment tools - one for metadata and one for Vlocity. In turn, this creates more problems:
You have to run extra deployments for Vlocity DataPacks in addition to your metadata deployments, which takes up more of your time.
It's inefficient having multiple tools for one job - in this case, deployments. It's easier for your team to have fewer tools to learn.
Your audit trail for deployments is split. If you're a Gearset user, you'll want Vlocity deployments in your deployment history so you can roll back, clone, redeploy, or combine those packages like every other deployment.
It's harder to integrate Vlocity deployments into your DevOps process, although it is possible to use Delta CI to deploy Vlocity components.
Gearset's Vlocity deployments are built on top of Vlocity Build.