Basic Concepts
The Visual Flow Designer is a visual tool for designing interactions between a skill and its users. The following topics contain the first things that you need to know.
Visual Designer
With the Visual Flow Designer, dialog flows are designed visually instead of through a code editor. The connections between states are represented in visual diagrams. Variables, parameters, and component properties are defined in specialized editors and dialogs.
Multiple Flows
In the Visual Flow Designer, you create flows to handle the various parts of the conversations you are designing your skill for. Typically you would have:
- The Main Flow, which is the main entry point for the skill and which is more
of a configuration than a flow. The main flow contains:
- Global variables.
- Events that map to flows.
- A flow for each regular intent.
- A single flow to handle all answer intents (though it is also possible to have separate flows for individual answer intents if you want to include behavior that is specific to those answer intents).
- Sub-flows and reusable utility flows (e.g. for authentication) that can be called by other flows.
Events
In skills created with the Visual Flow Designer, a flow is triggered when an event that is mapped to that flow occurs. There are events for each of the skill's intents and built-in events for standard cases (such as unexpected user input and errors). In addition, you can define custom events, which enable you to trigger flows based on actions emitted when another flow ends.
Events that are triggered at the skill level are mapped to flows. Events that are triggered in a flow are mapped to states in the flow. (In the case of Dialog Error events, if you haven't mapped the event to a state in the current flow, the event propagates to the Main Flow, from where it is mapped to a flow.)
Events in the Visual Flow Designer roughly correspond with default transition actions in YAML dialog flows.
Variables, Scope, and Parameters
With the Visual Flow Designer, you can define variables at the level of individual flows and globally.
- In individual flows. Variables defined in a flow can't be directly accessed
from outside of that flow.
The lifespan of a flow variable is limited to that flow. Its value is cleared after the dialog has traversed to the end of the flow. If a user returns to that flow later in the session, the variable is re-initialized.
- In the Main Flow. Variables defined here have a skill-wide
(global) scope, meaning that they can be accessed by all flows in the skill.
Values for these global variables persist througout the user's session with the skill. The variables are cleared when the user session with the skill ends, which happens when one of the following things occurs:
- The user closes the chat window.
- The session times out after a period of inactivity (the value of which is defined at the channel level and which is typically 24 hours).
- In the context of a digital assistant, the user exits the skill
or reaches a state that directly invokes another skill.
Note
When the user interrupts a conversation with a non sequitur input and is temporarily routed to a different skill, the digital assistant remains in the context of the original skill and its variables are not automatically cleared. In this case, if the user returns to the original skill after the interruption, the variables hold their values. If the user selects not to return to the original skill, the original skill is exited and the variables are cleared.
Values of variables can be passed in and out of flows by using input and output parameters. By using parameters instead of direct references to variables across flows, you make flows that are self-contained, which enables reusability, fosters predictable behavior, and reduces the likelihood of bugs.
The names of input parameters for a flow need to be distinct from the names of that flow's variables.
For more information on working with variables, see Expressions for Variable Values and Other Variables Types.
New, Modified, and Removed Components
The Visual Flow Designer's set of components is largely the same as in the YAML-based editor, but there are some additions, removals, and modifications. Here's a quick rundown of the biggest differences.
The following components are exclusive to the Visual Flow Designer:
- Invoke Flow: Used to call a flow from an existing flow.
- End Flow: Used to end a given flow. You can also use this component's
action
property to specify an event that triggers another flow. Typically, such an action would be used by an action transition specified in an Invoke Flow component in the parent flow. For top-level flows, the action in the End Flow state triggers the custom event in the Main Flow. - Send Message: A simplified Common Response (
System.CommonResponse
) component for displaying a message. - Ask a Question: A simplified Common Response (
System.CommonResponse
) component for prompting a user for a response. - Resolve Composite Bag: A simplified Resolve Entities
(
System.ResolveEntities
) component that is designed specifically to work with composite bag entities. - Display Tables and Forms components.
The following components are not available in the Visual Flow Designer:
- System.Intent: This functionality has been replaced by automatic intent resolution, which occurs when there is no active flow. See Intent Detection and Resolution.
- System.ConditionEquals: Use the Switch component instead.
- System.ConditionExists: Use the Switch component instead.
- System.Text: Use one of the Common Response Component Templates, the Resolve Entity component, or the new Ask Question component instead.
- System.List: Use a Common Response component template or the Resolve Entity component instead.
- System.Output: Use a Common Response component template, the Resolve Entity component, or the Send Message component instead.
- System.Qna: If you are using Q&A modules, you should migrate to the use of answer intents.
For a complete rundown of the components in the Visual Flow Designer, see Component Templates.