Create a Simple OmniScript

Learning Objectives

After completing this unit, you’ll be able to:

Explain what makes an OmniScript unique.
Add a Step with Inputs to an OmniScript.
Configure element properties.
Describe how data flows into and out of an OmniScript.
Configure OmniScript Action elements.

What Makes an OmniScript Unique?

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. Though not required, it is recommend to have an OmniScript’s Type start with a lowercase letter.

Settings for creating a new OmniScript

In this example, the OmniScript’s Type is team (1), its SubType is editAccount (2), and its Language is English (3). An OmniScript’s Name does not have to be unique in your org. Here, the OmniScript’s Name is Edit Account (4).

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.

In this example, Version 2 of the Team Edit Account OmniScript is active. The information is displayed in the OmniScript Header.

An OmniScript’s Version number and Active status displayed in the OmniScript Header

Add an OmniScript Step and Inputs

Steps are how you organize a page. Once you create your OmniScript, you then configure the Step.

How do you add a Step with Inputs to an OmniScript? Let’s start by looking at the Edit Account OmniScript from the last unit.

Completed Edit Account design using the OmniScript Designer

This is a simple one-step OmniScript. When you build it, first configure the single Step element with its inputs, and then add the Actions elements.

Adding Text (Name), Telephone (Phone), and URL (Website) Inputs elements to a Step

From the Build panel, drag a Step element onto the canvas.
Drag the following Inputs elements into the Step creating fields to display and allow the end user to edit data: Text (1), Phone (2), and URL (3).
Select the URL element, and enter Website for the Name and Field Label in the Properties tab.

Super! Now that you’ve added the Step and Inputs to the OmniScript, you’re ready to configure their properties.

Configure Element Properties

Many elements have the same types of properties. For example, each element must have a Name.

Element names must be unique in an OmniScript. Here are some other guidelines to follow.

Use Pascal Case and no spaces for element names (for example, StepAccount).
Use object and field names for clarity (for example, AccountName).
Specify the object for Ids (for example, AccountId).

For Display or Inputs elements, element labels are what the end users see on the screen. For Actions elements, element labels display in the Action Debugger. Labels do not need to be unique.

Let’s take a look at the element properties used to configure these features of the Edit Account OmniScript.

An end user’s view of an interaction

The Name field (1) is a read only field to prevent users from changing the account name anywhere other than in the Salesforce Account record itself.
The Phone field (2) is a required field, and marked with a red asterisk.
The Name, Phone, and Website fields don’t fill the width of the line.

How is this accomplished?

Property	How is it enabled?	What does it do?
Read Only	Select a checkbox.	Restricts the user from making changes to a field.
Required?	Select a checkbox.	Requires the end user enter data in the field before moving on.
Width Settings	On the Canvas, drag the responsive control width grid.	Adjusts the size of a field using HTML web standards (dynamic control).

When you finish configuring your Inputs elements, you’re ready to add Actions elements. Before you do that, though, let’s take a minute to learn about the way data flows into and out of an OmniScript.

How Data Flows into and out of an OmniScript

There are several data input options for an OmniScript. Using Integration Procedures is a best practice. We explain in detail why in the OmniStudio Integration Procedures module, but Integration Procedures allow you to separate data configuration from OmniScript configuration.

Here are the scenarios for using the other data input options.

For This Data Input Source	Use This OmniScript Element
Salesforce Org-One field only	Lookup; located in the Inputs section and uses DataRaptor extract service
Salesforce Org—Fields from one object only	DataRaptor Turbo Action
Salesforce Org—Fields from one or more related objects	DataRaptor Extract Action
API	HTTP Action
Anything that Apex can access	Remote Action
User	Any Inputs Element; located in the Inputs section and allows the user to input data

So, how do you move data from Salesforce to an OmniScript using an Integration Procedure? When an OmniScript is launched via an Action on a FlexCard, the RecordId is passed along the JSON in a node (in this example, it’s called AccountId). The RecordId is saved in the OmniScript in a variable called ContextId.

Data flow from a FlexCard to an OmniScript

Once the variable is in the OmniScript, pass the RecordId via a variable called AccountId to the data tool you plan to use. Following best practices, choose an Integration Procedure to pass the AccountId to a DataRaptor Extract. AccountId is an arbitrary name, but it must be the same in each of the elements in order for data to flow properly between them and Salesforce.

The DataRaptor Extract uses the AccountId in a Salesforce Object Query Language (SOQL) query to retrieve data from Salesforce. This includes the AccountId and data from the Account record. The DataRaptor Extract maps them to a data JSON, which is sent to the Integration Procedure and then to the OmniScript. The OmniScript uses a parser to match the JSON that comes from the Integration Procedure to the inputs in the OmniScript based on element names. If the JSON doesn’t match the element name, the fields will appear empty.

The data flow looks like this:

Data flow from an OmniScript to a data tool that extracts data from Salesforce

The user and other OmniScript actions manipulate the data while the OmniScript runs.

An updated data JSON, including the AccountId, is then passed to an Integration Procedure, which passes the JSON with AccountId to a DataRaptor Load. The DataRaptor Load uses the AccountId to identify the original account record and updates the data in Salesforce.

Data flow from an OmniScript to a data tool that saves data to Salesforce

Your job is to configure the Action elements to ensure the data flows in correctly from the FlexCard and out of the OmniScript back to Salesforce.

Configure OmniScript Action Elements

To configure OmniScript Action elements, return to the canvas. Let’s take a look at this example, which configures two Integration Procedure Actions, to understand how this works.

Two Integration Procedure Actions with one placed before and one after the Step element

From the Build panel, drag an Integration Procedure Action (1) onto the canvas. This calls an Integration Procedure that gets the data. Place the Action (2) above the Step element.
From the Build panel, drag an Integration Procedure Action (3) onto the canvas to call the Integration Procedure that saves the data. Place it below the Step element.

When placed outside a step, Actions execute automatically in the order they appear. When placed inside a step, an Action appears as a button that must be clicked before it executes.

Actions have their own naming conventions. Use a prefix for the element type, such as DR for DataRaptor or IP for Integration Procedure. Then use VerbObjectDetail. In the Edit Account OmniScript, IPGetAccountDetails is the name of the Integration Procedure Action (2) above the Step, and IPSaveAccountDetails is the name of the Integration Procedure Action (3) below the Step.

Each Integration Procedure Action has a dropdown list from which you select the Integration Procedure you want to call from the OmniScript. When you link an Integration Procedure to an OmniScript, the OmniScript sends the entire JSON to the Integration Procedure by default.

When the JSON is small, as it is in the Edit Account OmniScript, there’s no need to trim or redefine it. However, you do need to confirm what the ContextId is in that JSON. For the Edit Account OmniScript, for example, you need to tell the Integration Procedure that the ContextId is the AccountId.

But isn’t AccountId an arbitrary name? Yes, it is! Still, it’s important to follow the best practice of being explicit about what type of RecordId you are sending to an Integration Procedure.

When an end user completes the OmniScript, the Navigate Action tells the OmniScript where to send the end user. If an agent opens the OmniScript from a FlexCard on a console, you can configure the Navigate Action to return the agent to the console.

Once you have added the Navigate Action and previewed the OmniScript, don’t forget to activate it! And there you are. You have not only learned about the power of OmniScripts to guide end users through a process, you’ve learned how to design and create a simple one-step OmniScript.