You can think of flows as a folder in which you can put bot dialogs that are related to the same topic.
Keep in mind that flows, just like the connections between dialog states, are simply a way of organizing your bot. They do not restrict the movement of users across your bot.
Users can jump from one flow to another by using intents
Bot builders can set-up a next bot dialog to another flow
Some tips on choosing how to group flows:
Group all flows that have a functional relation. In our Choo Choo example, you could group all bot dialogs that are meant to help book a ticket, all general questions about trains, and all support flows (e.g. "I lost my bag on the train")
Reserve one flow for general questions, such as your offloading settings and the dialog for when your bot doesn't understand
Bot dialog flow builder
Bot dialog types
There are 4 kinds of bot dialogs, each with its own colour and functionalities:
Use this bot dialog type to gather input from your users.
Every bot dialog type has its own settings and NLP tab, which stays the same throughout the different types.
Bot dialogs menu
Our platform offers two different views of your dialog states, where you can configure what the bot will answer to a user.
The flow view: a visual representation of all your dialog states, where you can easily see which bot dialogs are related to each other.
The table view: the same information about your dialog states as in the flow view, but shown in a table, making it easier to filter, search and sort the dialog states.
The flow view shows your flows like a tree. This view is helpful to see how your flows are constructed. The parent child relations between bot dialogs visually organises the bot dialog states. Changing the parent child relation will not change the way your conversation flows work: it is purely for organising the bot dialogs in a logical matter. The user is only redirected by intent recognition or clicks on UI components such as buttons and quick replies.
View your bot dialog states as a table, which is helpful for searching, filtering and sorting dialog states.
Bot Dialog Settings
Bot Dialog ID
This is the ID associated with the dialog state. You can use this to debug your bot using the Emulator.
Bot dialog Name
The name for a specific dialog state. This is also the label that is shown in the tree view, the list view or the translations module. You can enter any name you want and change it as often as you like.
Bot Dialog Label
You may use this field as a custom identifier for your bot dialog when integrating solutions through the Webhook Channel API .
For example: say you want to store the number of times some specific bot dialog ( eg. Greeting Message ) has been triggered. You have added a custom label to that bot dialog ( eg. messages_greeting).
Now if you delete the Greeting Message and recreate it, its unique identifier on our side will change, but you could still add messages_greeting as the custom label again.
If you use this custom label in your system to check if the bot dialog has been triggered then nothing on your side needs to be changed, just make sure the label of the recreated bot dialog is the same as the label of the bot dialog you deleted.
The bot dialog flow determines in which flow the bot dialog you are editing (or creating) will be stored.
Parent bot dialog
The Parent Dialog State can be used to visually organise your dialog states. Changing the Parent Dialog State will not restrict the conversation flows: it is purely for organising the dialog states in a visual way on the canvas.
You can only choose a parent that is present in the flow you have selected.
Bot dialog NLP settings
Every bot dialog can be linked to an Intent. When a user is entering free-form text, it is analysed by the NLP model. If the model recognises an intent with a high enough accuracy (above the threshold), the user will get the bot dialog coupled to that intent. Multiple bot dialogs can reuse the same intent by using different Context settings. A dialog state can only be linked to one Intent.
Input contexts give more information about when exactly an intent can be used. If you specify an input context and the linked intent is recognised, the bot will check if the input context is active and act accordingly: combine multiple required contexts for sub flows in flows.
To set a required context for a certain bot dialog, type the name of your context in the Search or create required context field. If it doesn't exist, a new context will be created. An existing context will be reused. You can also click on the available contexts in order to select one.
If the required context is not active, this dialog state will not be shown, even though the intent linked to it was recognised.
If the required context is active, the dialog state will be shown.
Every bot, when created, has a set of standard bot dialogs.
The Bot Disabled bot dialog will only be triggered if you explicitly disable your bot. You can do this in the 'Settings > Bot' page. Let's say you want to disable the bot for 1 day, then you can show a message like 'At this moment I can not help you further, please contact our support service through <email> or call us on <phone> if you have any questions' in that bot dialog.
The error occurred bot dialog will be triggered if an API integration fails to complete a certain request. For example, let's say you perform an API call to an external system from an API Action bot dialog to retrieve details about a product. If the external API throws an error, the conversation will automatically be redirected to the Error Occurred bot dialog.
Whenever an intent is not recognized above your threshold, the bot will refer to 'not understood'. Please find more information on how to configure different 'not understood' options here.
The other system bot dialogs are specifically related to our Offloading feature (redirecting your users from the bot to a human). You can find more information about them in our documentation.