Execution
Last updated
Last updated
Xenioo executes each action in the order you see inside each Interaction. You can change this order by dragging and dropping each action inside the same interaction. In the same way, operations that are added as child of each action (for example a Go To below a button) can be changed of order by using the small up and down arrows you see near the the title.
Xenioo approach to chatbot building is to subdivide each action into smaller parts (Actions) that can be enriched by additional functionalities (Operations). Using this approach Xenioo is capable of keeping each action simple on the surface while allowing for a much greater configurability when diving deeper.
Each Xenioo Action is executed like a single function: as the function is evaluated and triggers and avent, child operations are executed. In the same way, operations that are triggering events will be executed and their child operations evaluated.
Using this approach, you can easily use each building block to create a visual function that Xenioo can execute for you.
As an example, let's say you want to redirect the user to a welcome interaction only if the VIP tag is enabled. Using pseudo-code, you would write something like this:
Using Xenioo unique Action & Operation composition, you would build the same thing like this:
Notice how the Go To operation isn't part of the Tag Switch. It is just an additional function we attach to the Tag Switch action.
Using the same composition criteria very complex scenario becomes trivial as it is easy, for example, to trigger API Actions on buttons that redirect to specific parts or sections while doing multiple operations.
Whenever the user interacts with the chatbot by either clicking on a content or typing something or sending a file, actions contained inside the current interaction are evaluated just like a virtual program. The result of this evaluation must produce an output of any kind (text, media etc.) to be sent to the user. If no content is generated by all the rules and an empty reply is generated, the flow is automatically redirected to the current behaviour Fallback interaction.
Xenioo supports some visual content set as child of conditional branch. A variable switch may test for a specific variable and display different text depending on the value, like in the example below:
When a visual content is returned by a branch, the branch execution is halted, regardless of whatever additional branches may still need to be visited.
Actions and operations can be set at three different levels:
On the Interaction
This is the most typical situation. You add multiple actions such as text and buttons inside each interaction.
On The Behaviour
When at behaviour level all operations are executed regardless of the interaction where the user is located. Inside behaviour operation you will add operations that need to be activated everywhere in that specific behavior. To access Behaviour level operations, click on the behaviour property icon on the designer toolbar. From there you can click on the Add Behaviour Operation button.
On The Bot
At Bot level you add all operations that need to be triggered wherever the user is interacting. Here are usually found NLP and Global Input switches for global questions. To access bot level operations, click on the global bot operation icon on the designer toolbar.
When the user types something as a reply to your chatbot, Xenioo will first execute all of the current interaction actions. If no action produce an output for the user, it will scale to check Behaviour operations and eventually scale further to Bot Global Operations.> If the user input triggers something at interaction level, additional Behaviour or Bot Global operations are not evaluated.
Some actions may halt execution of the current interaction actions to force a wait for user input. These actions will halt the conversation and wait indefinitely for the user to specify a specific value. When the execution is inside these actions not other local or global action can be evaluated. The flow will not continue until the user has fulfilled the request (or skipped the request if allowed by configuration).
Please refer to each action specific information to know when the action is blocking or not. As a naming convention, actions that are marked as "Input" are always blocking while actions marked as "Detection" are never blocking input.
