Chat bots are all about conversation, processing text coming in from a user, and at any point in that conversation the user could say anything. They might be answering a particular question being asked by a bot, or they might be interrupting the current discourse, or just saying something witty. What this means is that chat bots are not wired up like traditional user interfaces, there is no explicit connection between a button press and some specific action.
Instead, everything happens through text. Whatever the user types is sent to the Kora NL platform where it is evaluated and interpreted from a variety of angles and contexts. Clicking on button in the chat window, be it from a custom template, or an ambiguity message, or a list of choices, does nothing more than send the postback text to the platform just as if the user had explicitly typed it out. The buttons merely save typing and help to guide the user instead of them staring at a flashing cursor wondering what to say.
Now you don’t give any details as to how you have used this message node or the use case, so all I can do is describe some general situations.
Ordinarily a message node only generates output, and the dialog will continue on to the next node without waiting for anything from the user. There are two situations where a message can wait, or appear to wait, for a user response.
One is when the message node is the last one in the dialog. The message is sent, the dialog moves to completion and since there is nothing left to do the bot just sits there. Whatever the user types next, or simulates by pressing some button from that last message, will be interpreted as primary intent identification, i.e. another dialog, FAQ, or smalltalk. For anything meaningful to happen then you need intent training to match whatever the user “types”.
This is by far the most common use case - for example, many people use a welcome dialog that only has a message node to present a short list of common tasks where the postback text is aligned with intent training.
The other, more complicated, option is to explicitly force the message node to stop and wait for user input. But to do that then you need to add subintents as connections to the message node and explicitly change the rule to wait for user input. If a message node has any of these types of rules then it will pause the flow and the subsequent user input will be evaluated against the training for those subintents. But this is a fairly specialized scenario, so is perhaps not relevant here.
Now if what the user is indicating is not at the level of an intent then what you need to use is an entity node instead. Entities can pause the execution flow of a dialog to wait for a user’s response, the entity prompt can use all the same templates as a message node. The postback text is then first interpreted with respect to the type of entity and its associated training. The connections out of the message node can test the entity for different values.
In summary, everything is text, and how that text is interpreted depends on training, and that training can exist at an intent and/or an entity level.