You can think of flows as a folder in which you can put bot dialogs that are related to the same topic.
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
There are 4 kinds of bot dialogs, each with its own colour and functionalities:
Any message a bot is sending to a user is what we call a bot message. This includes text messages, buttons, quick replies, etc.
If you want to add rules to determine where a user is guided to, based on the value of a variable, you can do it with this bot dialog type.
Actions allow you to configure the settings of a user session, such as the language that will be used to reply to your user, or the offloading of a user.
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.
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.
This is the ID associated with the dialog state. You can use this to debug your bot using the Emulator.
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.
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.
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.
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.
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.
To learn more about using context, see our Context concepts documentation.
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.
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.