Dialogs as conversational building blocks in Composer
APPLIES TO: Composer v1.x and v2.x
Modern conversational software has many different components. Bot Framework Composer integrates these pieces into dialogs, a single interface for constructing the building blocks of bot functionality.
Each dialog represents a portion of the bot's functionality and contains instructions for how the bot will react to the input. Dialogs can include custom business logic, calls to cloud APIs, training data for language processing systems, and importantly, the actual content used in conversations with the bot's end users. Simple bots will have just a few dialogs. Sophisticated bots might have dozens or hundreds of individual dialogs.
In Composer, dialogs are functional components offered in a visual interface that reduces the need to write code. The dialog system supports building an extensible model that integrates all of the building blocks of a bot's functionality. Composer helps you focus on conversation modeling rather than the mechanics of dialog management.
Dialog types
You create a dialog in Composer to manage a conversation task. There are two types of dialogs in Composer: main dialog and child dialog. The main dialog is initialized by default when you create a new bot. You can create one or more child dialogs to keep the dialog system organized. Each bot has one main dialog and can have zero or more child dialogs. Refer to the Create a bot article on how to create a bot and its main dialog in Composer. Refer to the Add a dialog article on how to create a child dialog and wire it up in the dialog system.
Below is a screenshot of a main dialog named WeatherBot and three child dialogs called Cancel, Help, and getWeather.
At runtime, the main dialog is called into action and becomes the active dialog, triggering event handlers with the actions you defined during the creation of the bot. As the conversation flows, the main dialog can call a child dialog, and a child dialog can, in turn, call the main dialog or other children dialogs.
Anatomy of a dialog
The following diagram shows the anatomy of a dialog in Composer.
Recognizers
A recognizer interprets what the user wants based on their input. When a dialog is invoked, its recognizer will start to process the message and try to extract the primary intent and any entity values the message includes. After processing the message, both the intent and entity values are passed onto the dialog's triggers. Composer currently supports three recognizers: The LUIS recognizer, which is the default, the Regular expression recognizer and the custom recognizer that allows you to use your own custom recognizer. You can choose only one recognizer per dialog, or you can choose not to have a recognizer at all.
Recognizers give your bot the ability to understand and extract meaningful pieces of information from user input. All recognizers emit events when the recognizer picks up an intent (or extracts entities) from a given user utterance. The recognizer of a dialog isn't always called into play when a dialog is invoked. It depends on how you design the dialog system.
Below are the types of recognizers in Composer:
- Default recognizer: enables you to use the following different recognizers:
- Regular expression recognizer: gives you the ability to extract intent and entity data from an utterance based on regular expression patterns.
- Custom recognizer: enables you to customize your own recognizer by editing JSON in the form.
For more information, see Language understanding in Composer.
Note
Azure QnA Maker will be retired on 31 March 2025. Beginning 1 October 2022, you won't be able to create new QnA Maker resources or knowledge bases. A newer version of the question and answering capability is now available as part of Azure AI Language.
Custom question answering, a feature of Azure AI Language, is the updated version of the QnA Maker service. For more information about question-and-answer support in Composer, see Natural language processing.
Note
Language Understanding (LUIS) will be retired on 1 October 2025. Beginning 1 April 2023, you won't be able to create new LUIS resources. A newer version of language understanding is now available as part of Azure AI Language.
Conversational language understanding (CLU), a feature of Azure AI Language, is the updated version of LUIS. For more information about question-and-answer support in Composer, see Natural language processing.
Triggers
The functionality of a dialog is contained within triggers. Triggers are rules that tell the bot how to process incoming messages. Use triggers to define a various bot behaviors, from how to fulfill a user request, to how to handle interruptions, to how to handle developer-defined events. Below is a screenshot of the trigger menu in Composer.
For more information, see Triggers.
Actions
Triggers contain a series of actions that the bot will undertake to fulfill a user's request. Actions are things like sending messages, responding to user questions using a knowledge base, making calculations, and performing computational tasks for the user. The path the bot follows through a dialog can branch and loop. The bot can ask or answer questions, validate input, manipulate and store values in memory, and make decisions. Below is a screenshot of the action menu in Composer. Select the + sign below the trigger you can mouse over the action menu.
Language generators
As the bot takes actions and sends messages, a language generator is used to create those messages from variables and templates. Language generators can create reusable components, variable messages, macros, and dynamic messages that are grammatically correct.
For more information, see Language generation in Composer.
Add actions to dialogs
A bot can have from one to several hundred dialogs, and it can get challenging to manage the dialog system and the conversation with users. In the Add a dialog section, we covered how to create a child dialog and wire it up to the dialog system using Begin a new dialog action. Composer provides more dialog actions to make it easier to manage the dialog system. You can access the different dialog actions by clicking the + node under a trigger and then select Dialog management.
Below is a list of the dialog actions available in Composer:
| Dialog Action | Description |
|---|---|
| Begin a new dialog | An action that begins another dialog. When that dialog is completed, it will return to the caller. |
| End this dialog | A command that ends the current dialog, returning the resultProperty as the result of the dialog. |
| Cancel all dialogs | A command to cancel all of the current dialogs by emitting an event that must be caught to prevent cancellation from propagating |
| End this turn | A command to end the current turn without ending the dialog. |
| Repeat this Dialog | An action that repeats the current dialog with the same dialog. |
| Replace this Dialog | An action that replaces the current dialog with the target dialog. |
With these dialog actions, you can easily create an extensible dialog system without worrying about the complexities of dialog management.