Events are triggered when specific actions occur during conversation with the Virtual Assistant or when specific events are triggered on any active channels.
For example, when a user clicks the Get Started button to initiate a chat with your FB Messenger VA, it triggers the Facebook Welcome event. You can use this event to customize the welcome greeting such as personalizing it with the user’s first and last names, capturing additional information from users, and updating the back-end systems.
To generate the Get Started button, please use the following Curl code:
curl –location -g –request POST ‘https://graph.facebook.com/v2.6/me/messenger_profile?access_token={{page access token}}’
–header ‘Content-Type: application/json’
–header ‘Cookie: fr=0DjuarxRV9YWitxAN..BfXHzR…1.0.BfXHzR.’
–data-raw ‘{
“get_started”: {“payload”: “Facebook”}
}’
Note: You must provide access_token
, the Page access token for the specific Facebook page in the curl to run the API.
To access Event Handlers, navigate to Build > Intelligence > Events.
Event Actions
Developers can define the VA should take when an event is triggered using one of the following options:
Run a Task
Select a Dialog task (Standard or Hidden) to be invoked when the event triggers. Once the event is triggered, the dialog starts executing. If it is interrupted because of other intent detections, the Hold and Resume settings come into play. During execution, if the selected Dialog is not published in the VA, the event is discarded.
In some cases, the Dialog may not be available to the user during a conversation for various reasons such as the task not yet being published, being suspended, or simply not having been assigned to the user. In such cases, the VA shows an error message that the task is not currently available for execution. Developers can preempt such situations by testing the VA in Debug mode. The Debug Console shows full details about the error, including the reason why the task is not available.
Run a Script
Define a JavaScript to run when the event triggers. The script can make use of all applicable components such as session, context objects, variables, and functions. You can also fix the code using the Debug mode.
Show a Message
Define a simple or advanced message to the user when the event triggers. It supports all messaging formatting features available in the XO Platform, including multiple messages with channel override options.
Multilingual VA Behavior for Messages
- You can define language-specific messages;
- If a message is deleted from an Event for a specific language then it will be removed from all other languages of the VA;
- If a message is added for a language then the message would be added in all other languages using the same content;
- If a message is modified in a language, then the modifications will be applied for that language alone.
Learn more about message formatting and templates.
Event Types
Event Handlers are classified as Conversation Events, Intent Events, and Channel Events.
You can configure the following events to trigger responses:
Event | Trigger |
---|---|
Conversation Events | |
Welcome Event | On receiving the first message from the user from any channel. |
End of Conversation | On reaching the end of conversation. See details below. . |
Task Execution Failure | On encountering an error in dialog task execution like:
|
Intent Events | |
Intent not Identified | Runs every time the VA cannot understand the user’s intent. |
Channel Events | |
Facebook Welcome Event | On receiving a Welcome Event from Facebook Messenger. This event takes precedence over Welcome Event if both are configured. |
Telephony Welcome Event | On receiving a user’s call from a voice channel like IVR, Twilio, or Audio Codes. See details below.
(previously called Twilio Voice Welcome Event) |
Telegram Welcome Event | On receiving the Welcome Event from Telegram. This event takes precedence over Welcome Event if both are configured. |
On Connect | Every time a user converses over Web / Mobile SDK channels. The event will be triggered irrespective of whether the user has started the conversation or not.
Note that this event applies ONLY for Web/Mobile SDK channel and takes precedence over the Welcome event if both are configured. |
RCS Opt-in Event | On receiving the message that a user has opted for the RCS Messaging channel. |
RCS Opt-out Event | On receiving the message that a user has opted out of the RCS Messaging channel. |
Event Configuration
Conversation Events
Welcome / On Connect Event
Users can initiate VA conversations in varied ways, from a simple greeting to directly expressing an intent or asking an FAQ. To facilitate a scope for the developer to customize the response based on the user choice, the Welcome event comes with additional options when you choose Initiate Task or Show Message as the event configurations. For example, if the first user utterance maps to a task, should the VAexecute the event-based task or the user intent first?
Post ver9.0, you can use the isReturningUser parameter in the BotUserSession context object to identify returning users and send an appropriate welcome message (refer here for context object).
As a developer, you can define the VA’s priority when the user starts the conversation with a greeting, task, or FAQ from the options listed below:
Event Configuration | Options |
---|---|
Initiate Task |
If the Task is unavailable to the user for any reasons, such as not yet published or suspended or simply not assigned to the user, the VA shows an error message that the task is not currently available for execution. |
Show Message |
|
Note: The XO Platform no longer supports Welcome Messages. If you have defined a Welcome Message in previous versions, the upgraded version automatically creates a corresponding Welcome event and On Connect event to ensure backward compatibility. |
End of Conversation
End of Conversation is triggered when the VA is not expected to send any message to the user or receive any message from the user.
A new flag indicating the reason for ending the task, added to the end of task event, will help decide the end of the conversation behavior. Client-side implementations of BotKits, RTM, and Webhook channels can use this reason for the task completion flag in the context to determine an appropriate course of action.
On triggering this event, the context will be updated with the following details:
- Reason for triggering event (see the table below)
- Name of the task that has just ended. If it’s an FAQ, then the task name will be set to ‘FAQ’
Scenario | End of Conversation Flag |
---|---|
Reached the last node of the dialog | Fulfilled |
The task is canceled by the user | Canceled |
Error in task or FAQs execution (without Task Failure Event, no hold tasks) | Failed |
Linked dialog completed without returning to the parent dialog | Fulfilled_LinkedDialog |
On answering a FAQ | Fulfilled |
Successful event execution with Run Script or Show Message (no tasks on hold) | Fulfilled_Event |
Error in executing an event with Run Script or Show Message (no tasks on hold) | Failed_Event |
User declines to resume on-hold task (when no other task is on hold | Canceled |
Repeat Bot Response Event
The Repeat Bot Response event is triggered to repeat the last bot response when certain predefined or custom-trained utterances are detected in voice channels such as IVR, Audiocodes, or Twilio Voice. To enable this event, a bot developer must define the context object as a precondition for triggering the event. This context object contains the specific set of utterances that should be recognized to repeat the bot’s most recent or last response.
By configuring the context object with appropriate utterances, the bot can understand specific phrases or keywords from the user to trigger the Repeat Bot Response event. When one of these utterances is detected, the bot will repeat the last response
A bot developer can activate the Repeat Bot Response event and custom-train when this event can be triggered with conditions at any point in the conversation and can ask the bot to repeat its recent responses.
Note: The Repeat Bot Response event uses the NLU multilingual model for Non-English languages.
The following are some of the scenarios and the repeat bot response event behavior in those scenarios:
SCENARIO | REPEAT BOT RESPONSE EVENT BEHAVIO |
---|---|
In the middle of the conversation | Repeat event gets triggered. |
Conflict between Intent and Repeat event | Intent gets prioritized. |
Conflict between Sub-Intent and Repeat | Sub-intent gets prioritized. |
Conflict between FAQ and Repeat event | FAQ gets prioritized. |
Conflict between group node sub-intent and repeat event | Group node sub-intent gets prioritized. |
If the repeat event is enabled in a Standard VA and disabled in the Universal Bot (UB) |
UB settings take precedence, and the event defined in UB is triggered even if the current conversation context is in a Linked Bot. |
Use Case Scenario
Problem Statement
In the Flight Booking VA, the user couldn’t hear the last response on an IVR channel, and the user said, “Sorry, I can’t hear you. Can you please repeat it again?”
In this conversation, the dialog has reached the end, and the last response says, "Thank you. Your flight has been booked successfully. Your booking reference number is XYZ789 and you will receive a message shortly "
(Dialog reached to END).
Solution
If the conversation session is not closed or the call is not disconnected after the end of the dialog, the Repeat Bot Response event is triggered, and the last message of the dialog task is repeated when you configure a task in the End of Task event with a message that says “Is there anything else I can help you with?”
. For more information, see the End of Conversation article.
Now the ‘Repeat Bot Responses’ event considers the end of dialog after the ‘Last User Input’ configuration, the repeat response will say, “Thank you. Your flight has been booked successfully. Your booking reference number is XYZ789 and you will receive a message shortly. Is there anything else I can help you with?”.
Enabling the Repeat Bot Response Event
A bot developer uses the Repeat Bot Response to allow you to repeat the responses that users might have missed or if it is not clear during the conversation on an IVR channel.
Steps to enable the Repeat Bot Response event:
- Navigate to Build > Intelligence > Events.
- Click Configure to enable the Repeat Bot Response Event.
- Click Manage Utterance to review the pre-trained utterances that are added to the VA by default.
- You can add more utterances and click the Train link.
- Once Utterances are trained, you can add the following preconditions:
- Channels – Allows you to add voice channels such as IVR, IVR Audiocodes, or Twilio Voice.
- Context Tags – Allows you to add the context objects to trigger the Repeat Bot Response event. For more information, read the Context Object article.
Note: The context tags are added to trigger the repeat bot responses whenever the dialog task with that particular context is executed. For example, when a book a flight dialog task is executed, then the context tag will trigger the repeat bot response event for that particular dialog task.
- Select the Event Configuration options to define how to repeat the response:
- Repeat Only Last Bot Response – By default, this option is selected with a filler message:
Sure, I will repeat it for you.
- You can edit or add the filler message for the repeat bot response event before it is triggered.
- Click +Add Filler Message and select the IVR channel and enter the filler messages and then click Done.
- When the Repeat Bot Response event is triggered, these filler messages are used in the IVR channel conversation before repeating the response.
- Auto-generate Response – When you select this option, you are redirected to enable the Advanced NLU model, if not enabled, to generate the bot response using the LLM and Generative AI engine.
- Click Enable Now to define the Advanced NLU Settings for the LLM and Generative model and enable the Repeat Responses feature. Learn more.
Note: When the Auto-generate response option is enabled, the repeat bot response event will not use the filler messages that were defined in the previous step. The responses automatically sent from the LLM and Generative model when the event is triggered.
- Repeat Only Last Bot Response – By default, this option is selected with a filler message:
- Expand the Advanced Settings and define the following options to repeat the response:
- Repeat Attempts Limit – Set the number of retry attempts to repeat a response. The accepted value is between 1 and 10. The default is 5.
- Behavior on Exceeding Repeat Attempts – Define what VA must do after exceeding the number of retry attempts to repeat the response. You can choose either the End of Dialog or Initiate Dialog option.
- When you select the Initiate Dialog option, you can choose the task to which the conversation must be redirected after a number of retry attempts to repeat.
- Click Save & Enable to trigger the Repeat Bot Response event with the configurations.
Task Execution Failure Event
- This event is available starting with the v6.40 release.
- By default, this event is always enabled with the Show Message option. This event cannot be disabled.
- This VA-level behavior can be overridden for specific tasks by defining task-specific failure events from the dialog task settings. Refer here for how.
Intent Events
Intent Not Available Event
When the VA cannot understand the user’s intent, this event determines the subsequent behavior. You can choose one of the following options:
- Show a standard message from the standard responses. Read here for details on standard responses.
- Automatically run a dialog task. You can use the dropdown to select the task you want to run.
Ambiguous Intents Identified Event
When the NLP engine identifies ambiguous intents from user utterances, by default, the virtual assistant displays a list of those intents during the conversation and requests the user to make a selection. This default behavior is ideal for most of the use cases. However, you can customize this behavior for specific use cases using the Ambiguous Intents Identified event. The event is triggered in the following scenarios:
- Two or more ‘definite’ intents are identified.
- Two or more ‘possible’ intents are identified and their scores lie within the defined proximity thresholds.
- Only low confidence intents are identified from the Knowledge Graph and no other intents are identified from other engines.
You can build custom business logic to analyze ambiguous intents, define appropriate conversation flow using a Dialog Task, and associate it with the Ambiguous Intents Identified event. By customizing the flow, you can avoid displaying ambiguous intents to the end user and redirect the conversation to the desired task. You can use the koreUtil.getAmbiguousIntents()
function to retrieve the list of ambiguous intents and their confidence scores. For more information on the function, see koreUtil.getAmbiguousIntents().
Event Configuration
To configure the Ambiguous Intents Identified event follow these steps:
- Go to Build → Intelligence → Events on the platform. By default, this event is disabled for all existing and new bots.
- Click Configure to enable the event.
If not enabled, the list of ambiguous intents is presented to the user during the conversation. - You can select the following options in the Configuration panel:
- Present all the qualified intents to the end-user for disambiguation. This is the default selection in which the standard response related to the ambiguous intent(s) is presented. Learn more.
- Automatically run a Dialog Task. This option lets you select a Dialog Task. Select this option if you want to build custom business logic to analyze the ambiguous intents, define appropriate conversation flow using a Dialog Task, and associate it with the Ambiguous Intents Identified event. Learn more.
- Click the button Save & Enable to enable the event.
Interruption Management
When the event is enabled, the interruption behavior is handled as defined at the node level, dialog level, or bot level for ambiguous intents. The only exception is – when you select the Continue the current task and add new task to the follow-up task list option, the conversation continues as is with the current task, and any interrupting task will not be added to the follow-up list. For more information, see Interruptions Management.
Channel Events
Facebook & Telegram Welcome Events
This event triggers on receiving a Welcome Event from Facebook Messenger or Telegram. Once it is triggered, you can configure the Platform to perform the following actions:
- Initiate a Task: Select from the available Dialog Tasks to run once the event is triggered.
- Run a Script: You are shown a Javascript editor where you can add your script, which will run once the Facebook Welcome Event is triggered.
- Show a Message: This option lets you add VA responses to be sent to users once this event triggers.
Telephony Welcome Event
This event is triggered upon receiving a voice call to the Platform from any voice channel. This event will be triggered every time a user’s call reaches the Platform, and not just for the first time.
It provides the following two options:
- Initiate Task – Select a task to be triggered from the drop-down list provided
- Voice Call Properties can be set as follows:
- Define at least one ‘Initial Prompts’
- Prompts for Timeout, and No Match can be defined
- Under Advanced Controls, settings for Timeout, No. of Retries, and Barge-in can be defined.
See here for details.
IVR Impact
You may also use this event to define how and when the calls should be terminated for voice-based channels. The IVR implementation allows session/call closure only when the ‘end of conversation’ is completed. See more details here..
RCS Opt-In / Opt-Out Events
These events trigger when receiving opt-in or opt-out requests from users via the RCS channel. These events allow you to configure a response to be sent to the user as a follow-up for their action.
Variable Namespaces
You can configure Variable Namespaces for Events by going to More Options > Manage Variable Namespaces at the top of the Events screen.
You can use the Manage Variable Namespaces to associate the Variable Namespaces to be used with the Event Handler. This option will be visible only when the Variable Namespace is enabled for the VA. For more information, see Managing Namespace.