You are here:
Deployment of Omnistudio for Managed Packages Components Between Orgs (Managed Package)
For the managed package runtime, for your projects that use Omnistudio for Managed Packages, move the components and metadata from one org to another by using the Build Tool (formerly known as Vlocity Build Tool or VBT) or IDX Workbench. For simple use cases, you can move objects between orgs by exporting and importing data packs.
This information is for Omnistudio for Managed Packages. For Omnistudio on standard runtime, see Omnistudio Help.
Use DevOps methods to create solutions with Omnistudio in a dev org. Then deploy those Omnistudio components to a test or integration org, where you can do performance testing with data copied from your production org. Finally, deploy those components to your production org.
Select the tool for deploying components based on what you’re deploying, the data model used in the source and target orgs, and the Omnistudio runtime used in the source and target orgs. The source and target orgs can be sandboxes, development orgs, or production orgs. Regardless of the tool that you use, the components that are built on the custom data model used with Omnistudio for Managed Packages must be deployed separately from the components that are built on the Salesforce standard data model.
Key Differences Between Salesforce CLI and Omnistudio Build Tool
Consider these differences in capabilities before you choose your deployment tool:
| Features | Salesforce CLI | Omnistudio Build Tool |
|---|---|---|
| Version control | Matches the version of an Omnistudio component in the source org with the component version in the target org, and updates that specific version in the target org after it’s deployed. For example, you have a source org L1 and a target org T1, and you’re deploying an Omniscript GenerateLoanApplication version 4 from L1 to T1. Consider that there are seven existing versions of GenerateLoanApplication in T1. When you deploy GenerateLoanApplication version 4 from L1 to T1 by using Salesforce CLI, GenerateLoanApplication version 4 in T1 is updated during the deployment process. | Creates a version of an Omnistudio component when it’s deployed in the target org. |
| Component status | Matches the status of the Omnistudio components in the source org with the components in the target org when deployed. For example, you have a source org L1 and a target org T1, and you have an Integration Procedure GetInsurStatus version 4, which is in the active state in the source org. When you deploy GetInsurStatus version 4 to the target org, it updates GetInsurStatus version 4 in the target org and marks it as active. Similarly, if you deploy GetInsurStatus version 5, which is inactive, GetInsurStatus version 5 in the target org is updated with changes from the source org with the flag set to inactive. | By default, any Omnistudio component version that you deploy in the target org becomes active, and the last active Omnistudio component version becomes inactive. |
| Component dependencies | Doesn’t deploy the dependencies associated with an Omnistudio component, and it treats each Omnistudio component as a standalone metaxml file. For example, when you deploy an Omniscript that has a child Flexcard, Salesforce CLI deploys only the Omniscript as a standalone component without the child Flexcard. This flexibility helps users determine and choose which dependencies to deploy. Users can incrementally deploy only the files that they updated. | Deploys an Omnistudio component along with the associated dependencies when you deploy a data pack. You can deploy a data pack with dependencies and standalone components without the dependencies, or even decide the depth of dependency. |
| Component differences | Before you deploy, manually check the differences in an Omnistudio component in the source org and target org. This method is recommended for accuracy purposes. | Before you deploy, you can run a command to generate the list of differences in an Omnistudio component in the source org and target org. |
| Data pack format | View the Omnistudio components in XML format. | View the Omnistudio components in JSON format. |
Other Deployment Methods for Simpler Scenarios
- To move a small number of isolated components, you can use data packs. For example, if you have an Omniscript with a couple of Flexcards and some Integration Procedures or Data Mappers, you can use this method. But unlike the Build Tool, this method doesn’t validate or include every dependency.
- If you have several Omnistudio components and don’t need to set up a continuous integration or continuous development process, you can use IDX Workbench. Like the Build Tool, IDX Workbench validates and includes dependencies.
- The Salesforce Metadata API has a deploy() command for metadata. Omnistudio components contain metadata. You can't include setup and non-setup objects in the same deployment, so deploy Omnistudio components separately and don't include any other object. For example, if a Data Mapper references an object, deploy the Data Mapper and the object separately.
