OmniStudio Best Practices

In this post we will talk about Omnistudio Development Tools (FlexCard, OmniScript, Integration Procedures & Data Raptors) Best Practices. If you are new to OmniStudio Please check our Introduction to Salesforce OmniStudio session recording first.

Salesforce Industries (Vlocity) Digital Platform Components are divided in following categories.

1. FlexCard
2. OmniScript
3. DataRaptor
4. Integration Procedures

Let see the OmniStudio components best practices in details.

FlexCard

The Vlocity Cards Framework provides a robust set of components for building customer-centric, industry-specific UI components and applications on the Salesforce platform.

The FlexCard component contains a combination of data and links to processes within a specific context based on the data source. By default, a FlexCard loops through records returned from its data source and displays the list of records in containers called cards.

FlexCard Best Practices

FlexCards have strict naming conventions for their names and authors. Avoid spaces, dashes, and any non-alphanumeric characters. Use camel or pascal case for the name and don’t put two consecutive underscores next to each other. Here are names that adhere to the naming conventions. 

• teamGetAccount
• team_get_account

OmniScript

You can create OmniScripts to guide users through sales and service processes with fast, personalized responses, and seamless integration to enterprise applications and data. You can create OmniScripts using an intuitive drag-and-drop editor that enables you to group various elements such s actions (extract data, send email), functions (formulas), input fields, and branching logic.

OmniScript OmniStudio Best Practices

The Omniscripts best practices can be categorized as below.

1. Business Process
2. User Interface
3. Omniscripts design principles
4. Performance Factors

1. Business Process

Business process and logical best practices for omniScript are:-

1. Use one owner for each OmniScript.
2. Identify reusable elements by building a skeleton of the entire OmniScript.
3. Document the purpose of an element in the element’s Internal Notes property.
4. Maintain a golden copy for each OmniScript which supports when multiple developers working on same OmniScript. It also avoids issues when multiple teams to handle the same OS.
5. Standard templates can be overridden for each OS element, but it is recommended only to modify the CSS, not recommended to mimic the elements with custom HTML/JS templates. Vlocity upgrade doesn’t support the custom HTML elements.
6. Maintain DataRaptors and Apex classes by avoiding element name changes.
7. Avoid assigning a ContextId within the OmniScript. OmniScript’s ContextId is a reserved key that assigns a Record Id from the URL.
8. When processes are repeatable across multiple OmniScripts, create a reusable OmniScript, and add it to the appropriate parent OmniScripts.

2. User Interface

Omniscripts use lightning web components to define the styling for both individual elements and the Omniscript itself. Here are some best practices.

1. Create custom lightning web components that extend an Omniscript element’s component to apply styling changes.
2. Use global branding by using Newport Design System.

3. Omniscripts Design Principles

1. Prefill : Minimize the amount of data your users must enter by using the context to prefill any available key information.
2. Display only essential information : Whenever possible, remove information that is optional or tangential to your use case.
3. Keep it short : To minimize the cognitive load on your users and ease their decision-making, divide long, complex processes into short, easy-to-understand passages. Minimize the number of elements
4. Use sequence to aid understanding: Put input fields in an order that makes sense for your use case. Use Block elements under steps only if required for your use case.
5. Guide the user : Provide informative, actionable help text and feedback in the UI.

4. Performance Factors

A set of best practices exists for both Client-side performance and Server-side performance.

Client-side best practices include:

1. Reduce Conditional Views, Merge Fields, Formulas where possible.
2. Speed up the application of responses by trimming the Response JSON. For more information.
3. Remove spaces from element names to improve the OmniScript’s load time.
4. Reduce the number of elements in the script. A single OmniScript should not exceed 200 elements.
5. Run logic on the server where possible, including conditional logic in Integration Procedures and formulas in DataRaptors.
6. Test performance by enabling time tracking. If time tracking is not used in production, disable the feature before deploying to production. For more information.

Server-side best practices include:

1. Cut down the payload size of a request by trimming the JSON request. For more information.
2. Reduce server roundtrips by using Integration Procedures whenever multiple actions run between steps. Run Integration Procedures asynchronously by enabling the fire and forget property.
3. Remove unnecessary data by trimming the DataRaptor extract output.

OmniScript Naming Conventions.

An OmniScript’s Type, Subtype, and Language gives an OmniScript its unique identity. Only one active OmniScript may have the same Type, SubType, and Language at any time. An OmniScript’s Type must start with a lowercase letter.

Only one version of an OmniScript may be active at a time. If you need to make a change to an active OmniScript, create a new version. The version of the OmniScript already active and in production remains in place while you work on the new version.

1. Use camelCase – prefix, Verb, Object and Detail
2. Use an action verb and descriptive nouns
3. Use abbreviations
4. Example acctMgmt/verifyCallerteam

Considerations when working with OmniStudio FlexCards

1. OmniStudio auto-compiles a LWC every time you activate your FlexCard, therefor there are some limitations in regards to the size of that auto-generated component. Each file within an LWC component folder cannot exceed 131 072 characters. FlexCards allow for nesting child FlexCards and those are separate LWCs, so you should/ must consider creating multiple smaller FlexCards to reduce the chances of hitting this limit.
2. Custom LWCs increase the size of the auto-generated HTML a lot due to no dynamic import support on platform.
3. Make your event listeners unique to avoid firing the same event handler more than once! Use the option to concatenate the {recordId} and other context variables.
4. Auto-generated LWCs start with c-cf-**
5. Do not modify the auto-generated LWCs

DataRaptor

DataRaptor is a mapping tool that enables you to read, transform, and write Salesforce data. There are four types of DataRaptor:

1. Turbo Extract: Read data from a single Salesforce object type, with support for fields from related objects. Then select the fields to include. Formulas and complex field mappings aren’t supported.
2. Extract: Read data from Salesforce objects and output JSON or XML with complex field mappings. Formulas are supported. We can data from one or more Objects.
3. Transform: Perform intermediate data transformations without reading from or writing to Salesforce. Formulas are supported.
4. Load: Update Salesforce data from JSON or XML input. Formulas are supported.

DataRaptor OmniStudio Best Practices

Here are some DataRaptor Best Practices in Vlocity.

1. Use Limit in Dataraptors
2. Extract DataRaptor should not query more than 5 objects
3. Create targeted DataRaptors that only extract or load the data needed for one operation.
4. Use relationship notation (queries) whenever possible to pull data from other SObjects.
5. Try to keep the number of SObjects to three or fewer.
6. Ensure that all filtering and sorting (ORDER BY) operations are on indexed fields. The Id and Name fields are always indexed.
7. Use caching to store frequently accessed, infrequently updated data.

DataRaptor Naming Conventions

1. DataRaptor Names Must be unique within the org and there should be No spaces
2. Use camelCase – prefix, Verb, Object and Detail
3. Use an action verb and descriptive nouns
4. Use abbreviations
5. Example : prefixVerbObjectDetail and teamGetAcctCases

Integration Procedures

Vlocity Integration Procedures are declarative, server-side processes that execute multiple actions in a single server call. Integration procedures can read data from Salesforce and from external systems (using REST calls), and can call Apex code.

An Integration Procedure can be called from an OmniScript from an API, and from Apex code, and can serve as a data source for Vlocity cards. Integration procedures are optimal when you need to access and transform data from third-party sources and no user interaction is required and moving the workload from client to server is desirable.

Benefits of Integration Procedures over Apex Classes.

Backend Service Complexity	Build Time Apex	Build Time OmniStudio Integration Procedures	% Reduction in Level of Effort & Duration Using OmniStudio Integration Procedures
Easy	2 hours	30 minutes	75%
Difficult	6 weeks	1 day	97%

Integration Procedures OmniStudio Best Practices

To maximize the benefits of Integration Procedures, follow these best practices whenever possible:

1. Use Integration Procedures for all data calls to Salesforce.
2. Use Try catch block in integration procedure instead of writing apex code
3. Use a Response Action to trim the data and only return what is needed.
4. Use multiple Response Actions with different Execution Conditional Formulas to allow an Integration Procedure to exit early under appropriate conditions.
5. Use caching to store frequently accessed, infrequently updated data.
6. To run data operations asynchronously, call Integration Procedures using these settings:
   1. Use Future — Use when the calling OmniScript or Integration Procedure doesn’t need a response and completion time is not critical.
   2. Invoke Mode: Fire and Forget — Use instead of Use Future when the calling OmniScript must invoke the Integration Procedure immediately.
   3. Invoke Mode: Non-Blocking — Use to run the Integration Procedure immediately while continuing the user interaction of the calling OmniScript. A response is returned when the Integration Procedure is complete

OmniStudio Integration Procedures/Dataraptors Caching

Using a cache to store frequently accessed, infrequently updated DataRaptor and Integration Procedure data saves round trips to the database and improves performance.

If you use OmniStudio, DataRaptors and Integration Procedures use the Scale Cache. If you use OmniStudio for Vlocity, DataRaptors and Integration Procedures use the Platform Cache

OmniStudio Best Practices Video

Summary

I hope this post will help you to learn about Vlocity Best practices. After this session, you should be able to tune OmniStudio features for performance and have a low maintenance code.