Design and Build a Branching OmniScript

Learning Objectives

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

• Build branches into OmniScripts.
  
• Add conditional branching to an OmniScript.
  
• Use element properties to change the UI and UX of an OmniScript.
  
• Manipulate and inspect OmniScript JSON.
  

Before You Start

Before you take this module, we recommend you complete the OmniScripts module. The concepts here build on what you learn in that module. 

Build Branches into Guided Interactions

For a quick refresher, OmniScripts let you easily create customized, guided user paths through business processes, without complicated coding. They’re a fantastic solution for meeting user interaction requirements and providing seamless and engaging customer experiences. 

These guided interactions are most successful when they present end users with a clear, compliant, and direct path through a process. OmniScript branching is one way to provide just that. In this module you learn the ins and outs of OmniScript branching by exploring a simple example. 

There are a few ways to create branching in OmniScripts. You can create branching that displays specific steps in an OmniScript based on conditions—for example, an OmniScript with two branches that trigger based on customer age. If the customer is under 18, the branch only allows them to edit their contact information. If they are over 18, the branch allows them to edit their contact information, select a new service plan, and receive offers. 

Or you can create branching that displays blocks of fields based on conditions—for example, an OmniScript that displays certain fields when the user checks a box. If, while updating their billing address, an end user selects a checkbox to indicate they also wish to update their mailing address, the mailing address fields appear. 

Let’s get acquainted now with the OmniScript branching example in the module. 

You want to design an interaction that helps customer service agents change an account’s primary contact details. 

“As a customer service agent, I want a guided interaction for an account that provides me with options to update the contact information for the existing primary contact, change the primary contact to another existing contact I can easily look up (and edit their contact information), or create a new contact and assign them as the primary contact.”

Here’s how this interaction appears to service agents.

All OmniScripts require the following elements: 

• at least two data sources (the best practice is to use OmniStudio Integration Procedures),
  
• at least one Step to display inputs, and
  
• a Navigate Action to direct the end user at the end of the interaction.
  

There are two requirements that add some complexity to our OmniScript example.

• A page that lets the agent view and select options for what they want to do—they may only choose one option at a time.
  
• A second page with groups of fields that conditionally display based on the option the agent chooses.
  

Let’s see which OmniScript elements help you meet these two requirements. 

The steps in this module are for demonstration purposes only. OmniStudio is not enabled in Trailhead Playground orgs.

For the first requirement, use radio buttons as the Inputs elements. Unlike checkboxes, agents can select only one radio button at a time. This prevents the end user from accidentally selecting multiple options. 

For the second requirement, Conditional Views applied to individual elements display groups of fields based on the radio button the agent selects. You decide that the OmniScript has one Step that presents the choices and a second step that contains  three different Blocks. This allows you to organize different fields within each Block. 

Branch 1: Update Primary Contact

Take a look at the example. Branch one, the Update branch, has three fields. Two  display the first name and last name of the current primary contact and the other allows you to update that contact’s email address.

Branch 2: Change Primary Contact

Branch two, the Change branch, displays a field that lets you search for and select a new primary contact. The search is limited to the existing contacts linked to the account.

Branch 3: Create a New Primary Contact

Branch three, the Create branch, displays three fields that are the minimum fields needed to create a new contact and make them the new primary contact.

Your newly designed OmniScript has multiple Blocks in one Step, but only displays one Block based on user input (the radio button they select). So, How do you actually configure the OmniScript so it branches like this? Link the radio buttons to their corresponding Blocks with a Conditional View. By pairing radio buttons and Block elements via a Conditional View, you display a Block based on user input while hiding the others. The end user only ever sees one Block at a time. This makes the page very user-friendly, because it only displays fields related to the task at hand: updating, changing, or creating a new primary contact.

Now let’s explore how element properties help you provide a better user interface (UI) and user experience (UX).

Use Element Properties to Change the UI and UX of an OmniScript

Have you ever walked away from an online interaction because the webpage’s poor design made a task time-consuming and difficult? The UI and UX of an interaction are critical to its success. Fortunately, it’s easy to use element properties to enhance the UI and UX of an OmniScript! 

Let’s say you want the email field for a Primary Contact to display in an OmniScript, but don’t want end users to be able to leave  this field empty. The solution? Make the field required with the click of a checkbox. This simple adjustment of element properties ensures a seamless customer experience. 

There are other UI settings you can configure easily with standard element properties. 

• Adjusting the dynamic control width of a field (the relative width it has on the page).
  
• Making a field read-only (the end user cannot edit the field).
  
• Hiding fields from view that are not meaningful to the end user but are needed on the backend.
  
• Providing tooltip help text (lets end users hover their cursor to discover what a field is for).
  

OmniScript Step elements have their own UI settings you can configure.

• Create clear and concise instructions that complement the information already in the UI.
  
• Customize the Step Chart (the list of steps that appear in the UI).
  

You’ve learned how to adjust element properties to improve UI and UX. There’s still more to discover!  Let’s say that you have those three Blocks on the page but only wish to display one at a time based on end-user input: Update, Change, or Create. What’s the solution? 

Add Conditional Branching to an OmniScript

Enter conditional branching.  You’re ready to add the radio buttons to the first Step. As you configure the properties, you link each of the Blocks in the second step to a different radio button or choice. Now your three Blocks will display one at a time based on end user input.

How does this work? Remember, almost every element in an OmniScript lets you define conditional views. As mentioned earlier, when you set up the radio button element, you link each choice to a Block on your page via these conditional views. This is conditional branching in a nutshell. 

Once you’ve done this, add the data elements to bring in data. It’s also key to check this data is flowing into and out of the OmniScript by inspecting the Javascript Object Notation (JSON).

Manipulate and Inspect OmniScript JSON

Let’s return to our example. You’ve designed an OmniScript using conditional branching that helps service agents update, change, or create a primary contact. Now it’s time to add the data elements to bring in the data, and then check that the data is flowing into and out of the OmniScript by inspecting the JavaScript Object Notation (JSON).

When you add elements that work with data, such as Integration Procedure Action elements, use the following properties to do more complex data mapping and manipulation. 

When you’ve configured your Step and added elements to bring data into the OmniScript, use Preview to confirm the branching is working as expected. In Preview, you can see a preview of the OmniScript, inspect the JSON, and use the Action Debugger to confirm data is moving back and forth between the OmniScript and your data tools. 

All of this branching business is pretty exciting, right? In the next unit, you learn how to add a Type Ahead Block to create the Change primary contact branch.

Resources

• Trailhead: OmniScripts