In this session we will talk about basic of OmniScripts. OmniScripts are a way for a application builder to design a business process by configuring interactions using declarative tools that are easy to use, and it implement complex functionality behind the scenes. It enables you to craft dynamic customer interactions without code.
OmniScripts provide ability to configure interactive, easy-to-use business processes with branching, which means different pages and groups of fields can be shown based on choices the user makes.
What is an OmniScripts?
An OmniScript allow you to build a guided path for completing a business process and serves as a configurable way of creating a seamless customer experience. You can create OmniScripts using an intuitive drag-and-drop editor that enables you to group various elements such as actions (extract data, send email), functions (formulas), input fields, and branching logic.
You can enable the LWC on OmniScript to get an LWC component that you can deploy and launch from Communities, Object detail pages, and FlexCards.
Advantages of OmniScript
- Drag and drop with no or low code
- Rapid prototyping, with built in troubleshooting tools
- Ease of maintenance
- Branching capability built in
- Integrating data from almost any source
- The look and feel (front end) separated from functionality (back end)
When to use OmniScripts?
Here are a some example when you can use OmniScripts.
- Provide a guided path to complete a business process.
- Step users through complex tasks
- Captures details for a service implementation.
- A customer steps through a selling process, such as choosing a new insurance plan.
- For self-service interaction such as troubleshooting.
In OmniScript there are the different types of elements and how they can be used.
|Actions||For calling on other tools to perform various actions: getting or saving data, calculating, sending an email, and so on|
|Display||For displaying text and images on the screen to enhance the usability of the UI|
|Functions||For performing calculations within the OmniScript, showing conditional messages, and providing geolocation|
|Group||For grouping elements together on the UI|
|Inputs||For system or user input or selection|
|OmniScripts||Reusable OmniScripts to insert and use|
Reusable OmniScripts are intended to be embedded into another OmniScript so they have no Done Action.
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.
OmniScript Naming Conventions Best Practices
- Use camelCase – prefix, Verb, Object and Detail
- Use an action verb and descriptive nouns
- Use abbreviations
- Example acctMgmt/verifyCallerteam
When to use OmniScript and Screen Flows
What is difference between OmniScript and Salesforce Screen flows. When to use OmniScript and Screen flows?
- OmniScript should be the default option for external personas for industry use cases
- Screen Flows should be the default option for employee-facing use cases
- If you can reuse Screen Flows or OmniStudio for both Employees & Customers, you should.
OmniScripts Performance Factors and Best Practices
Let talk about OmniScript best practices in OmniStudio. A set of best practices exists for both Client-side performance and Server-side performance.
Client-side best practices include
- Reduce Conditional Views, Merge Fields, Formulas where possible.
- Speed up the application of responses by trimming the Response JSON. For more information.
- Remove spaces from element names to improve the OmniScript’s load time.
- Reduce the number of elements in the script. A single OmniScript should not exceed 200 elements.
- Run logic on the server where possible, including conditional logic in Integration Procedures and formulas in DataRaptors.
- 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:
- Cut down the payload size of a request by trimming the JSON request. For more information.
- Reduce server roundtrips by using Integration Procedures whenever multiple actions run between steps. Run Integration Procedures asynchronously by enabling the fire and forget property.
- Remove unnecessary data by trimming the DataRaptor extract output.
OmniStudio’s tool for building guided interactions. If you are new to OmniStudio then please check our complete Free Training on OmniStudio.