Vlocity packages are becoming increasingly popular as a way to extend Salesforce quickly with sector-specific solutions. But for many teams, deploying Vlocity means using a dedicated deployment tool and a separate workflow to your normal Salesforce deployments — not an ideal solution. With Gearset, you can deploy your Vlocity DataPacks alongside Salesforce metadata.
What is Vlocity?
Vlocity was acquired by Salesforce in February 2020 and rebranded as Salesforce Industries. The two names are still used interchangeably — for the sake of ease, I’ll use “Vlocity” in the rest of this post.
Companies choose Salesforce as their CRM because it’s easy to customize for particular business requirements. But most companies in any given sector will have broadly similar requirements, and so Vlocity offers sector-specific solutions as packages that companies can install into Salesforce. In broad strokes, these solutions meet the typical requirements companies have in particular sectors, and then Salesforce teams can adjust the fine details for further customization.
Why are Vlocity deployments different?
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 DataPacks can’t 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.
How to deploy Vlocity DataPacks using Gearset
Gearset’s Vlocity deployment solution dovetails with its metadata deployment tool, so you can deploy Vlocity items using the same interface and include Vlocity items alongside metadata in your regular deployments. Gearset gives you more granular control over these deployments than Salesforce’s deployment tools.
Here’s a quick walkthrough of a Vlocity deployment in Gearset.
First, let’s make a change to one of the FlexCards in a developer org. We open up OmniStudio from the App Launcher, go to OmniStudio FlexCards and select the FlexCard we want to edit — in this case gearsetMasterAccount. We deactivate the card and make a simple change, switching the colour of the icon header from blue to orange, then reactivate the FlexCard.
Next, we’re going to use Gearset to compare that developer org with a staging environment, and then deploy our change to the FlexCard. Opening up Gearset’s filter from the bottom right of the Compare and deploy page, we can see the list of metadata types we could include in the comparison. But Vlocity items aren’t metadata, so we select the tab labelled Vlocity types to include.
This opens up a list of all the Vlocity types you can compare and deploy. We made a change to one of our FlexCards, so we need to select VlocityCard. If we had made changes to other components such as DataRaptors or IntegrationProcedures then we’d need to select those as well.
Let’s close the filter and click on the Compare now button. Gearset compares the two environments and shows us the exact difference between them. We can see the change to that FlexCard, so we select it to deploy and click Next.
There are no warnings flagged up by Gearset’s problem analyzers for this deployment, so we can proceed straight to the deployment summary where Gearset shows us what we’re deploying. We can give the deployment a friendly name so our teammates will get a quick idea why we ran the deployment, and now we’re ready to deploy! We could schedule the deployment for later, but let’s click Deploy now.
The deployment is successful! We can click on the new Deployed Vlocity items tab to view the change we deployed.
Combined Vlocity and metadata deployments
You can easily deploy Vlocity items alongside metadata in the same deployment. Just include the relevant types in Gearset’s comparison filter and select all the changes you need from the comparison page. On the Deployment summary page, you’ll see separate tabs for metadata items and Vlocity items for you to review everything that’s going to be deployed.
Gearset will deploy your metadata first, then the Vlocity items. When you view your deployment history in Gearset, you may see some deployments that have the status Partial. This means the metadata was successfully deployed but not the Vlocity items.
Adding Vlocity items to your Salesforce DevOps process
As well as deploying Vlocity DataPacks manually, you can also use Gearset to include Vlocity deployments within an automated DevOps workflow.
Let’s run through an example of setting up a CI job from a GitHub repository that integrates Vlocity items. We can then see how the process works by making a simple change to the color of a Vlocity FlexCard.
1. Set up a CI job in Gearset
First, let’s set up a CI job between the main branch of a Git repository and a Salesforce org. The CI job will be triggered whenever changes are merged into main, and will deploy them to our specified Salesforce org. We could also configure the CI job to run on a periodic basis — if we wanted to.
In the continuous integration dashboard, click Add new deployment job. We can choose anything for the source and target, from Salesforce orgs to Git repos hosted by any provider such as GitHub, BitBucket or GitLab. In this case, we want to select the source as a GitHub repository and then choose our main branch. For the target, we select a Salesforce staging org and set the CI job to run whenever the source branch is updated.
Then, under the Metadata filter tab, we can choose the metadata types to include. Here’s where we’ll also be able to find the group of Vlocity types, by clicking on Vlocity types to include in the bottom left. We can check these boxes in the exact same way we select other metadata types. In this case, from the Vlocity types we’re only selecting VlocityCard, OmniScript, IntegrationProcedure and DataRaptor.
Once we hit Save, a new dialog will appear to set up a webhook on GitHub — this can be done automatically or manually. A webhook allows Gearset to detect when there are changes in the repo we’ve selected, and we can choose which events will trigger the webhook, like pull requests and pushes.
Once the webhook has been added, we can go into the settings of our GitHub repository and check that it’s listed there.
2. Make a change to a Vlocity FlexCard in a developer org
In a Salesforce development environment, we’re going to make the same change we made for the previous walkthrough. First we deactivate the FlexCard, and then change the background color of the FlexCard. After reactivating, the color change has been made.
3. Compare and deploy the change to the GitHub repository
In Gearset, we’ll head to Compare and deploy and make a comparison between our developer org and the main branch of our Git repo (it’s worth noting that normally we’d create a feature branch and deploy to that first before merging into main). We open up the metadata comparison filter at the bottom to choose what items we want to include in the comparison. Just as when setting up the CI job, you’ll see both metadata types and Vlocity types. Here, we’re using a pre-saved filter, “Vlocity only”, including only the four Vlocity types mentioned earlier. Clicking Compare now will start the comparison.
When we reach the comparison view, we can see that there’s one changed item of the VlocityCard type. Gearset shows us that the background color has been changed, just as expected. We can just check the box for that change and then click Next.
On starting the deployment, Gearset’s problem analyzers run, checking if there are any deployment-blocking problems such as missing dependencies in the deployment package. There are no problems with this package, so now we get a summary of the items we’re deploying. Here we can add a friendly name for the deployment, leave a commit message, and update any Jira tickets. Once we’re happy, we can commit the change to our branch in Git.
4. Verify the change in the CI job’s target environment
After committing the VlocityCard change, the CI job that we set up earlier will have been triggered automatically, and the change should have instantly deployed to our Salesforce org. We can check that the color change has been made by going into our staging org and opening an account in the OmniStudio Console to see that the background color of the FlexCard has changed to orange.
Try deploying your Vlocity DataPacks!
If you’re using Vlocity, have a go at deploying your DataPacks using Gearset. As always, we’re keen to hear your feedback on any improvements that we can make to this or any part of the app. If you’re not a Gearset user, you can start a free trial, giving you full access to Gearset for 30 days.