Design a Simple OmniScript

Learning Objectives

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

• Describe the OmniScript element types and their uses.
  
• Summarize steps for determining which OmniScript elements an interaction requires.
  

Examine OmniScript Elements

OmniScripts are built by moving elements into the canvas and defining their properties. These elements are placed in a specific sequence for the workflow. There are elements for:

• User interaction on the user interface (UI).
  
• Getting, saving, and manipulating data behind the scenes.
  

OmniScript elements are grouped by type, based on the kind of functionality they perform, and they each have settings that must be configured appropriately.

Here are the different types of elements and how they can be used.

Ready to break it down a bit more? Let’s do it!

Actions elements

Action elements are used to:

• Get data from one or more Salesforce records (Omnistudio Data Mapper Extract Action).
  
• Update the data in one or more Salesforce records (Omnistudio Data Mapper Post Action).
  
• Call a series of actions (Integration Procedure Action).
  
• Get, save, or delete data through a web application programming interface (API) (HTTP Action).
  
• Populate and send an email as part of an interaction (Email Action).
  
• Send DocuSign emails for signature or sign DocuSign emails (DocuSign Envelope Action and DocuSign Signature Action).
  
• Send the user back to a previous page after the interaction is complete (Navigate Action).
  

Display Elements 

Display elements let you provide important context within the workflow or help you with the layout of the page.

Display elements include:

• Line Breaks element: Allows you to create a line break to control the spacing on the page.
  
• Text Block element: Allows you to add instructions, images, and hyperlinks.
  

Functions Elements

Functions elements are commonly used to:

• Perform average/sum calculations (Aggregate).
  
• Perform formula functions and algebraic calculations (Formula).
  
• Display warnings, errors, and other feedback to users based on conditions (Messaging).
  

Groups Elements

Use these elements to group items together, such as the step/page view. For example, Step elements group interaction items onto one view or page. They are the UI canvas for a step in the flow.

Another type of Groups element, Type Ahead Blocks, includes a combination of functionality that provides autocomplete and search. For example:

• The user begins to enter information.
  
• The system searches for matches and displays a list of the matching items.
  
• The user then chooses the appropriate item.
  

Other commonly used Groups elements include:

• Block: Group elements together within the page/view.
  
• Edit Block: Add, edit, or delete records in real time.
  
• Radio Group: Group radio buttons such as when a user has common choices on a questionnaire.
  

Inputs Elements

Inputs elements enable user input. With these element types, a user:

• Enters information, such as payment method (1), the payment date (2), and the payment amount (3).
  
• Selects one or multiple options (4).
  
• Selects a checkbox.
  
• Enters or views text, a phone number, an email address, or a website.
  

This example shows the Radio element as payment method buttons (1) and fields used to pre-fill data such as last paid date (2) and amount (3).

An OmniScripts element (Child OmniScript) calls an OmniScript to reuse it within another one. This allows you to create smaller “child” OmniScripts for common functionality, such as showing specific contact or account fields.

This example shows several reusable OmniScripts to include as part of any OmniScript being built, if needed.

You’ve got tons of tools at your disposal as you design OmniScripts, as you can see. But how do you determine which ones to use? In the following example, you see how customer requirements give your project focus and help you determine the OmniScript elements you need.  

Choose Elements for an Interaction

Here’s an Account FlexCard that displays the customer's name, phone number, and website, and includes an Edit Account action.

Clicking this action won’t do anything yet; but soon, it will launch a guided interaction that allows a customer service agent to change the account details. However, you need to design this interaction first.

Let’s review the initial requirement for this interaction:

“As a customer service agent, I want a guided interaction that allows me to review and change customer account details, such as phone number and website, from the console.”

Here’s how this interaction could appear to service agents.

You determine the OmniScript must have these features that are visible to the agent:

• A page for the interaction
  
• A way to view the account name and edit the account’s phone number and website
  
• A way to control the spacing of these fields on the page
  

Which OmniScript elements will you choose to meet these requirements? Here’s what you need.

• First, you need to create a page for the interaction. To create a page for the Edit Account interaction, you need a Step element (Groups type). The step will be the canvas for the Inputs elements you want to include.
  
• Next, you need a way to view the account name, and a way to edit the account’s phone number and website.
  

Sounds like you need a few Inputs elements.

A Text element seems like the best choice for the account name, as it’s just a single line of text. However, you don’t want OmniScript users to change the account name, so adjust the element properties to make this field read-only. 

You want users to be able to edit the phone number and website.

• For the phone number, let’s use the Telephone element so the phone number formats automatically and the agent doesn’t have to worry about formatting it inconsistently.
  
• For the website, let’s use the URL element, as this requires http:// or https://. This also helps ensure consistent data entry.
  

Finally, you want a way to control the spacing of these fields on the page. This sounds like a display requirement, so you should look at the Display element options. 

You want to ensure the fields (inputs) remain on separate lines within the UI. To that end, you’ll add two Line Break elements to your design, one between the Account Name and Phone Number fields, and another between the Phone Number and Website fields.

Now you can focus on what capabilities you need on the backend.

• A way to get the account record data from Salesforce
  
• A way to save the data updates back to Salesforce
  
• A way to complete the interaction so the agent can get back to the card that launched it
  

It sounds like it’s time to check out your Actions elements. You’ve heard through the grapevine that Integration Procedures are an optimal way to get and save account data. Therefore, we’ll add two Integration Procedure Actions elements to the design. One of the actions will call the Integration Procedure that gets the data, and one will call the Integration Procedure that saves the data.

The placement of these actions in your OmniScript is important.

• Place the first one before the Step element (not inside it), as the data needs to be fetched before the agent can edit it.
  
• Place the second one after the Step element (again, not inside it), as the changed data can only be saved back to Salesforce after the agent changes it.
  

You’re almost there... Now you just need an Actions element that allows the agent to complete the interaction and return to the FlexCard that launched it. Here you choose the Navigate Action, which you can configure to redirect the user back to the Account card when they click Next at the end of the interaction.  

Congratulations! You completed your design of the Edit Account OmniScript. Here’s what it looks like when it’s built in the OmniScript Designer.

That’s one nicely configured OmniScript. In the next unit, you get to build it!