Message from user
In this section, we will cover the input event in detail.
The "user input" event is responsible for the message from the subscriber. When a message is received on the channel connected to the script, this event fires.
On the right you will see the event block settings. Let's take them in order:
The name of the event allows you to set any name of the block that is convenient for searching. This field does not affect the execution logic in any way.
The next block indicates the block that the bot will execute immediately after the event occurs, that is, immediately after receiving a message from the user.
In the IF conditions section, you can specify different conditions for checking a message or user data, or even use complex conditions in the internal SmartQuery language. A separate article is available about conditions and different types of comparison.
The "global input" checkbox means that this event will always be checked when the bot cannot process user input while already in the current scenario.
For example, the bot is already running in your scenario and performing actions. But then the user writes something that is not intended by your script (for example, you expect the user to answer, and he enters an option that is not provided by the condition.
In this case, instead of completing the scenario, the bot will go through the conditions of those events within the current scenario, in which the "global entry" checkbox is checked.
Sometimes it can happen that several event conditions fire at once. For example, you can make 2 events with exactly the same conditions, or use the "similar to" fuzzy comparison mode. In this case, by default, the bot uses a random chain.
But you can influence this behavior by specifying the chain priority.
The higher the priority, the earlier the block condition will be checked. Therefore, if there are several conditions triggered at the same time, the bot will choose the one with the higher priority.
This way you can control the highest priority chains of dialogs or, conversely, make "backup" lower priority chains that will work if the priority ones did not work.
Last modified 11mo ago