--- schema_version: "1" id: 9b4db12f5d8f89ee1343b9da3cc75a507881c61e0f909d1810baeae0fed93846 title: Deployment of Omnistudio for Managed Packages Components Between Orgs (Managed Package) collection: admin version: current locale: en-us portal_url: https://docs.salesforce.com/admin/current/en-us/xcloud/264-0-0/os_deploy.md canonical_url: https://help.salesforce.com/s/articleView?id=xcloud.os_deploy.htm&release=264.0.0&type=5 source_site: help.salesforce.com content_type: documentation content_hash: a171479ff59157f4121b8d7a26ed6b8bac050347e1a22c8ae4c61187a3522403 description: 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. products: - Omnistudio release: "264" --- # 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. ![Managed Package app icon](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-omnistudio_for_managed_packages-264-0-0-production-enus/aa2554ec-624a-4ee6-8da4-6435670e6e62/resources-global/_corporate/images/managedpackageicon.png) This information is for Omnistudio for Managed Packages. For Omnistudio on standard runtime, see [Omnistudio Help](https://help.salesforce.com/s/articleView?id=xcloud.os_omnistudio_standard.htm&language=en_US). ![Important](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-omnistudio_for_managed_packages-264-0-0-production-enus/aa2554ec-624a-4ee6-8da4-6435670e6e62/images/icon_important.png) Important Do not use Salesforce CLI when operating on a managed package runtime environment. 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. ![Note](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-omnistudio_for_managed_packages-264-0-0-production-enus/aa2554ec-624a-4ee6-8da4-6435670e6e62/images/icon_note.png) Note Deployment of components between orgs and migration from Omnistudio Vlocity to Omnistudio Standard are different processes. See [Deploying Omnistudio Components Between Orgs or Migrating from Omnistudio for Managed Packages (Managed Package)](https://help.salesforce.com/s/articleView?id=xcloud.os_deploy_or_migrate.htm&release=264.0.0&type=5 "For the managed package runtime, deployment means moving Omnistudio components from one org to another, whether you use Omnistudio for Managed Packages or Omnistudio. Migration means migrating your data from the Omnistudio for Managed Packages custom data model to the Salesforce standard data model and switching to the Salesforce standard runtime. Omnistudio migration includes migration of Omnistudio metadata only."). 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. ![Warning](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-omnistudio_for_managed_packages-264-0-0-production-enus/aa2554ec-624a-4ee6-8da4-6435670e6e62/images/icon_warning.png) Warning If you deploy setup objects that contain actions, access issues can arise. See [Objects That Can’t Be Used Together in DML Operations](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm). ## Key Differences Between Salesforce CLI and Omnistudio Build Tool Consider these differences in capabilities before you choose your deployment tool: ![Note](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-omnistudio_for_managed_packages-264-0-0-production-enus/aa2554ec-624a-4ee6-8da4-6435670e6e62/images/icon_note.png) Note We recommend that you use Salesforce CLI for deployments if you’re on standard runtime with standard objects. | 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. | ![Note](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-omnistudio_for_managed_packages-264-0-0-production-enus/aa2554ec-624a-4ee6-8da4-6435670e6e62/images/icon_note.png) Note Omnistudio Build Tool generates and deploys Omnistudio Lightning Web Components for each deployed Omniscript and Flexcard post activation in the target org. ## Other Deployment Methods for Simpler Scenarios - To move a small number of isolated components, you can use [data packs](https://help.salesforce.com/s/articleView?id=xcloud.os_data_deployment_with_datapacks.htm&release=264.0.0&type=5 "For the managed package runtime, a data pack is a collection of components and related functionality that are packaged for deployment between orgs. For example, you can use data packs to deploy functionality from a sandbox environment to a production environment."). 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()](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy.htm) 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. #### See Also - [Differences Between Omnistudio and Omnistudio for Managed Packages (Managed Package)](https://help.salesforce.com/s/articleView?id=xcloud.os_differences_between_omnistudio_and_omnistudio_for_vlocity.htm&release=264.0.0&type=5 "For the managed package runtime, Omnistudio and Omnistudio for Managed Packages differ in a few ways, but the key differences are the data models, the features available in each, and how you access each suite depending on your org licenses. Think of Omnistudio and Omnistudio for Managed Packages as two versions of an application suite, not two types of packages. While Omnistudio uses the standard object model, Omnistudio for Managed Packages uses the custom object model. That difference is why the two versions don’t have exactly the same features.") - [Data Deployment with the Omnistudio Build Tool (Managed Package)](https://help.salesforce.com/s/articleView?id=xcloud.os_data_deployment_with_build_tool.htm&release=264.0.0&type=5 "For the managed package runtime, the Omnistudio Build Tool (formerly Vlocity Build Tool or VBT) is a Node.js command-line automation tool that packages and deploys Salesforce data packs in a source-control-friendly format. The tool creates a YAML (YAML Ain’t Markup Language) manifest that describes a deployment project. The Build Tool enables continuous integration of Omnistudio metadata to source control.") - [IDX Workbench Desktop Application (Managed Package)](https://help.salesforce.com/s/articleView?id=xcloud.os_idx_workbench_desktop_application.htm&release=264.0.0&type=5 "For the managed package runtime, IDX Workbench is a desktop application that you use to deploy Omnistudio data packs and Salesforce metadata. Its user interface is built on top of the Omnistudio Build Tool. The application is available for Mac and Linux.") - [Data Deployment with Data Packs (Managed Package)](https://help.salesforce.com/s/articleView?id=xcloud.os_data_deployment_with_datapacks.htm&release=264.0.0&type=5 "For the managed package runtime, a data pack is a collection of components and related functionality that are packaged for deployment between orgs. For example, you can use data packs to deploy functionality from a sandbox environment to a production environment.")