What is a Conversational Screen?

Understand what a Conversational-type Screen is and how they work.

Overview

Design functional rule-based modern chat style experiences with Conversational-type Screens, also called Conversational Screens. When a Conversational Screen renders, that Screen displays as a streaming interactive chat box from which the Request participant interacts with the automated chat.

Conversational Screens are intended for use with Web Entry so that the chat experience can be integrated to any third-party site, such as your company and Support portals or any site to which your customers visit frequently. Therefore, Conversational Screens can be used by specified authenticated users or any anonymous person, depending on how the Web Entry for a Start Event element is configured.

Design Conversational Screen Modularly

Conversational Screens are designed to be modular so that both the data for that Request as well as the validation and visibility rules within the current Conversational Screen determine the course of the automated chat.

For example, one Conversational Screen may contain only four controls. The first control may be a Select List control, of which its Variable Name setting value (Request variable) is ask, that displays the options described below from which the Request participant selects one.

The following table describes the content of each option that displays in the Select List control as well as the Request variable value that stores the content in Request data.

Content of the Select List Control Option	Value of the Option Stored in Request Data
Start a Purchase Order	order
Track the Delivery of My Purchase	track
Contact Support	support

The subsequent three controls remain hidden by default unless the Visibility Rule setting value evaluates to show that control based on the selected option from the Select List control ask. Use the Label setting in controls, such as for Line Input controls, to display the text for the conversation response (except for Rich Text controls that use the Content setting to display its content).

The following table describes those subsequent controls by type, the text that displays in the conversation if that control displays, the visibility rule setting that displays that control, and subsequent actions in the Request.

Control Type	Content or Label	Visibility Rule Setting to Display Control	Subsequent Action(s) in Request
Rich Text	Let's start a purchase for you.	ask == "order"	Routes to a Sub Process element to start a child Request of "Purchase Request" Process.
Line Input	What is the Order ID for your purchase?	ask == "track"	Entered value routes Request to Exclusive Gateway element that evaluates same the expression, and then routes to a Script Task element to get order status. Thereafter, an interstitial Screen displays until Script Task returns order status to display in subsequent Conversational Screen. See Link Conversational Screens Together.
Rich Text	I'm adding you to the Support queue now.	ask == "support"	Routes to a subsequent Form Task element configured with a Self Service Task. The next available Support agent self-assigns that Task and contacts the Request participant.

Link Conversational Screens Together

Link Conversational Screens together while the Request resumes routing based on previous conversational responses by the participant. To provide a seamless conversation, select an interstitial Screen to display in the chat box after each Start Event element and/or Form Task element that is part of the overall conversation during workflow in that Request. An interstitial Screen is a Screen that displays after each Conversational Screen completes until the next Conversational Screen in that Request loads, thereby linking the Conversational Screens together into a seamless conversation for the Request participant. An interstitial Screen may be of Display-type.

Each Request's automated conversation may vary depending on how the Request participant responds to Conversational Screen interactions.

An effective interstitial Screen appears as if the Request participant interacts with a person. For example, design a Screen that uses an Image control that displays an animated GIF to imply that the other conversational participant is typing.

Animated GIF in Image control for a Screen to link between Conversational Screens

While the interstitial Screen displays, multiple elements and/or connectors may perform automatic tasks between one Task's Conversational Screen and the next during a Request. For example, a Data Connector connector may access a Collection record or call a third-party Application Program Interface (API) endpoint, and then return information that the Request participant requested in the conversation. However, the Request participant experiences a seamless conversation between the two Conversational Screens' Tasks while the interstitial Screen displays in the chat box.

For any of these elements that use a Conversational Screen, select the Display Next Assigned Task to Task Assignee setting, and then select the interstitial Screen that displays until the next Conversational Screen displays. The interstitial Screen displays until the next Task's Conversational Screen loads regardless of whether other elements and/or connectors trigger between the two Tasks using Conversational Screens.

Conversational Screen Design Guidelines

Follow these guidelines when designing Conversational Screens and linking them together for a cohesive chat-style conversation with a Request participant:

• Design each Conversational Screen modularly within the overall purpose of each conversational outcome. For example, solicit a response from the participant by asking a question with options from a Select List control. Allow the Process model to evaluate the flow of the conversation based on that and/or previous responses, and then in a subsequent Conversational Screen display the automated conversational feedback based on the participant's response. For example:

  1. Configure each Start Event element that provides access to initiate a chat from the hosting site, such as your company and Support portals or any site to which your customers visit frequently. By using Web Entry, the Start Event element specifies who may start a Request of that Process: any anonymous person or specified authenticated users. Since the Start Event element starts the Request, use a Conversational Screen that greets the Request participant. Then, select an interstitial Screen to display after that Conversational Screen completes until the subsequent Conversational Screen loads, such as this example.

  2. From each Start Event element configured using Web Entry, copy the JavaScript from the Embed Code setting, and then embed it into your the hosting site's header from which to initiate chat conversations.

  3. From each Start Event element configured using Web Entry, configure how the chat experience displays from within the hosting site, including the icon that displays to initiate a chat, its placement in the hosting site, and the appearance of the chat box.

  4. Configure each Form Task element that is a segment of the automated conversation with Web Entry and its Conversational Screen. Select an interstitial Screen to display after that Conversational Screen completes until the subsequent Conversational Screen loads.

  5. Use gateways, such as Exclusive Gateway elements, to route each Request based on responses from the Request participant's interactions in each Task's Conversational Screens.

  6. Design automated work in between elements that use Conversational Screens to get or submit information the Request participant request or requires via Conversational Screens. For example:

     • Data Connector connectors and Scripts get or submit entered information to a Conversational Screen.

     • Actions By Email, Send Email, and Slack Notification connectors communicate with relevant stakeholders during the Request and optionally allow them to make decisions based on information the Request participant entered into Conversational Screens during the automated chat.

     • PDF Generator connectors generate PDFs to send printable hard copies to the Request participant for receipts or purchase orders.

• Use mustache syntax to incorporate previous participant responses into the automated conversation based on an entered values. For example, at the beginning of the automated conversation, ask for the participant's name in a Line Input control in which its Variable Name setting value is Name. Name becomes part of the Request data. In a subsequent control in this or another Conversational Screen, use How may I help you today, {{ Name }}? in a Rich Text control to personalize the conversation.

• Use control validation rules to ensure the Request participant enters responses within the parameters of the conversation you expect for the Request.

• Use control visibility rules to indicate which control(s) display as responses and subsequent questions to the Request participant. These visibility rules "steer" the conversation with the participant based on past responses. Remember that visibility rules can reference Request variables not created in that Conversational Screen, but are added to Request data from another Screen in that Request.

Related Topics

pageDeploy Conversational Screens Using Web EntrypageWhat is a Screen?pageScreen TypespageProcess Modeling Element DescriptionspageConversational Forms PackagepageWhat is a Package?