Essential Preparations Before Transitioning to Salesforce OmniStudio Standard from OmniStudio for Vlocity

Introduction: Unlocking the full potential of Salesforce OmniStudio involves migrating from OmniStudio for Vlocity to OmniStudio Standard. In this guide, we'll explore the steps and considerations necessary to seamlessly transition to OmniStudio Standard, enabling you to leverage its enhanced features and functionalities.

Understanding the Transition: Salesforce OmniStudio Standard offers a suite of enhancements specifically tailored for standard object data models. Migrating your custom DataRaptors, FlexCards, Integration Procedures, and OmniScripts to OmniStudio Standard is crucial to take advantage of these enhancements effectively. The migration process is facilitated by the OmniStudio Migration Tool, a Salesforce command-line interface (CLI) plugin in Salesforce Developer Experience (SFDX), ensuring a smooth transition from custom objects to standard objects.

Key Considerations: Before diving into the migration process, it's essential to understand some key considerations:

• Who should use the migration tool?

If your organization relies on custom objects and utilizes any OmniStudio package excluding the Salesforce Communications, Media, and Energy (CME) package, the OmniStudio Migration Tool is your go-to solution. It seamlessly facilitates the migration process, ensuring a smooth transition to standard objects and standard runtime. However, it's important to note that the CME package does not support migration to standard objects or standard runtime.

• Why migrate your content?

In standard OmniStudio, utilizing the standard OmniScript and FlexCard runtimes alleviates the need to generate and deploy a Lightning Web Component (LWC) for every custom component. This streamlines the deployment process, saving valuable time and reducing complexity. Additionally, OmniScripts and FlexCards can be activated seamlessly without the need for manual intervention.

• Where to run the migration tool?

Ensure to execute the migration tool solely within a dedicated sandbox org. Under no circumstances should the tool be run in a production org. This precautionary measure ensures the integrity and safety of your production environment during the migration process.

• What does the migration tool do?

The OmniStudio Migration Tool efficiently transfers OmniStudio metadata, including active DataRaptors, FlexCards, Integration Procedures, and OmniScripts, from custom objects within the Vlocity OmniStudio managed package to the standard object data model. Following the migration process, you'll utilize the Metadata API to push the migrated metadata out of your migration org.

It's important to note that IDX Workbench and OmniOut, though essential components, do not fall under the OmniStudio package and therefore do not necessitate migration.

• What’s the process for migrating content?

In broad strokes, the migration process entails several key steps: preparing your content for migration, executing the migration tool within a sandbox org, conducting comprehensive testing of the migrated content, and finally, deploying it to the production environment.

Migration Process Overview: The migration process involves several key steps:

1. Get Ready: Prepare for Migration: Firstly, delve into the Differences Between OmniStudio and OmniStudio for Vlocity. Familiarize yourself with their distinct data models, available tools, and access criteria based on your org licenses.Next, explore the Products and Features Support for both OmniStudio and OmniStudio for Vlocity. Recognize that OmniStudio, leveraging standard objects, provides support for features and tools that may not be available in OmniStudio for Vlocity, built on Vlocity custom objects.Considering LWC OmniScript Considerations is crucial. Depending on your setup, make necessary adjustments to your environment prior to migration. For instance, if you're utilizing Angular OmniScripts or FlexCards, ensure a smooth transition by migrating them to the LWC OmniScript framework to maintain support. Failing to do so may result in their functionality ceasing post-migration.Furthermore, keep in mind that the OmniStudio Migration Tool does not migrate custom labels. You'll need to recreate them in standard runtime manually.Here's a concise Pre- and Post-migration checklist overview to guide you through the process:Pre-Migration:

• Address any unsupported features and upgrade customized functionalities.
• Assign permission set licenses to users.
• Install or upgrade to the Winter '23 or later OmniStudio package.
• Set up at least two sandbox orgs.
• Enable the OmniStudio Metadata setting.
• Execute the migration tool in your standard runtime sandbox org.Post-Migration:
• Rectify Custom Functions in Metadata and APEX references.
• Update namespace from vlocity_xxx to omnistudio in custom Lightning web components and Apex classes.
• Manually recreate custom labels in standard runtime.
• Replace any custom OmniScripts and FlexCards with standard components in the standard runtime sandbox org.
• Test the migration thoroughly by previewing the migrated objects in the OmniStudio designer and conducting additional testing in the UAT sandbox.
• Disable the OmniStudio managed package post-testing.
• Utilize Metadata API to deploy the UAT sandbox to the production org.

2. Considerations Regarding Runtime: In the OmniStudio landscape, it's essential to comprehend the nuances of runtime functionalities. Within a Salesforce organization, you can have both OmniStudio content utilizing the custom object model and content utilizing the standard data model concurrently. This setup allows for the incremental migration of custom content, facilitating a seamless transition.

• Understanding Object Models and Runtimes

Object models within OmniStudio delineate the metadata foundation of various components like FlexCards, OmniScripts, DataRaptors, and Integration Procedures. Two distinct object models exist: custom and standard.

Meanwhile, runtimes dictate the user interface experience within OmniStudio designers. There are two primary runtimes: custom and standard. While standard runtime remains enabled at all times, custom runtime can be toggled on or off. When custom runtime is disabled, all custom objects cease functioning, and designers default to standard runtime. Notably, designers can only save content in a single data model at any given time.

Objects constructed on the standard data model are compatible with both standard and custom runtime. However, objects constructed on the custom data model are exclusively compatible with custom runtime.

• Runtime Characteristics of DataRaptors and Integration Procedures

By default, DataRaptors and Integration Procedures operate using the standard runtime. Exceptions occur in specific scenarios:

• If standard runtime is disabled and RollbackDRChanges is set to true, DataRaptors utilize the custom runtime.
• If standard runtime is disabled and RollbackIPChanges is set to true, Integration Procedures leverage the custom runtime.

This logic extends to previewing DataRaptors and Integration Procedures within their respective designers, as well as invoking them via API or Apex.

• Runtime Transition for OmniScripts and FlexCards

Post-migration to the standard object data model, migrating components to standard runtime becomes imperative. This transition can occur en masse or incrementally, facilitating efficient testing.

For a comprehensive migration, backward-compatible Lightning Web Components prove invaluable. Activating Standard OmniStudio Content and utilizing the Deploy Backwards Compatible LWC feature enables the seamless generation of custom LWCs with standard runtime compatibility.

Alternatively, an incremental migration approach allows for meticulous testing. Temporarily enabling Standard OmniStudio Content permits the migration of select OmniScripts and FlexCards to standard runtime, ensuring a smooth transition. Subsequent testing verifies the effectiveness of the redeployed components before finalizing the transition.

3. Migration Considerations for OmniStudio Objects: As you embark on the migration journey for your OmniStudio objects, it's crucial to understand the disparities between your existing custom content and the migrated versions. Here's a breakdown of key considerations for each component:

Migration of Integration Procedures: Let's delve into the distinctions between custom Integration Procedures and their migrated equivalents.

• Vlocity Tracking: Error logging and tracking within Vlocity do not generate records for Integration Procedures executed in standard runtime from OmniScripts or FlexCards. However, you can utilize the Test Procedure feature to obtain insights into these Integration Procedures. When executed as Test Procedures, data is still written to the corresponding objects.
• Cache Blocks: Following migration, the caching mechanism transitions from the Platform Cache to the Salesforce Scale Cache.Usage metrics for Integration Procedure caches within the Platform Cache cease to display in Setup.Clearing the Scale Cache directly is not feasible. Nevertheless, within your organization, you can deactivate it for OmniStudio by incorporating an Omni Interaction Config record with Name = TurnOffScaleCache and Value = true.Existing Apex APIs within the managed package cannot be employed to clear caches.
• Calculation, Expression Set, Matrix, and Decision Matrix Actions: Standard runtime exclusively supports Expression Set Actions. If you're transitioning standard objects to custom objects during migration, it's advisable to also migrate calculation matrices to the Business Rules Engine Migration.
• The Intelligence, List, and OmniForm Actions are deprecated. If you're currently using any of these, please reach out to Salesforce Support for assistance.

Migration of Omniscripts: Let's delve into the distinctions between custom OmniScripts and their migrated equivalents.

• Angular OmniScripts: Angular OmniScripts are transitioned by the OmniStudio Migration Tool into the standard object data model. Yet, if these OmniScripts hinge on Angular functionality, they become dysfunctional. To ensure continued support within OmniStudio, it's imperative to reconstruct these migrated Angular OmniScripts into standard Lightning Web Component OmniScripts.

Migration of DataRaptors: Let's delve into the distinctions between custom DataRaptors and their migrated equivalents.

• Is Process Super Bulk Feature: While this capability isn't accessible in standard runtime, recent updates in OmniStudio have substantially enhanced performance, rendering this feature unnecessary. It's recommended to use smaller batch sizes for processing large workloads.
• Input Type = SObject: The sObject InputType can serve as a default interface object; however, it wasn't supported as a Picklist option. In the Spring ‘23 release, support for sObjects was reinstated, and they now function as expected as default interface objects.

Migration of FlexCards: Let's delve into the distinctions between custom FlexCards and their migrated equivalents.

• Vlocity Cards: Unfortunately, the OmniStudio Migration tool doesn't facilitate the migration of Angular or Lightning Web Component (LWC) Vlocity Cards. While Vlocity Cards share sObjects with FlexCards, they operate on a distinct schema, and the FlexCards code doesn't accommodate them.
• Vlocity Actions: Similarly, the OmniStudio Migration tool doesn't handle the migration of Vlocity Actions. If a FlexCard relies on a Vlocity Action, it's necessary to transition the Vlocity Action to a supported FlexCard action type with equivalent functionality.

4. Sandbox Orgs for OmniStudio Migration: Before embarking on the migration journey for your OmniStudio custom objects to the standard data model, it's essential to establish a robust sandbox environment. Here's a detailed breakdown of setting up sandbox orgs for seamless migration:

• Setting Up Sandbox Orgs: Ensure at least two sandbox orgs are configured to facilitate thorough testing and editing of migrated objects before transitioning to production. These sandbox environments serve as crucial testing grounds to validate the functionality and integrity of your migrated content.
• Standard Runtime Sandbox Org: This dedicated sandbox serves as the hub for migrating OmniStudio content. Execute the migration tool, a Salesforce CLI plug-in, within this org to initiate the migration process. After migration, disable custom runtime and preview the migrated objects using OmniStudio designers to ensure seamless functionality.
• Custom Runtime Sandbox Org (Optional): Designated for editing custom content yet to be migrated, this sandbox retains custom runtime enabled. When ready to migrate specific objects, utilize the Metadata API to push them to the standard runtime sandbox org and initiate the migration tool.
• UAT Sandbox Org: As a full sandbox replica of your production org with OmniStudio license enabled, this environment facilitates comprehensive testing of newly migrated standard objects. Validate the functionality in an environment mirroring your production setup before transitioning to the live environment.
• Production Org: Upon completing migration and rigorous testing, your production org becomes the new home for migrated content. Update all OmniStudio processes to reference standard objects. Utilize the Developer Console to disable custom runtime, ensuring a seamless transition to the standard data model.

Conclusion: Understanding these preliminary steps is paramount to ensuring the readiness of your organization for the migration process. In my forthcoming article, I'll delve into the intricacies of the actual migration process and outline the subsequent steps to be taken post-migration. Stay tuned for valuable insights and guidance on navigating through this crucial phase of your OmniStudio journey.

In crafting this blog post, I drew inspiration from a variety of sources and referenced several insightful articles and resources. I extend my gratitude to https://developer.salesforce.com/ and https://help.salesforce.com/