.png%3Falt%3Dmedia%26token%3D5eafba86-93d5-4f97-b243-b2bf0af6c24a)
.png%3Falt%3Dmedia%26token%3D5eafba86-93d5-4f97-b243-b2bf0af6c24a)
Notifications with the TRIGGER block
Since the TRIGGER block can be used to trigger specific events for any user of the chatbot, we can use it to send two-way chatbot notifications to other users or even perform some background tasks like affiliate tracking. Let’s look into a couple of simple examples.
There is a number of use cases when one chatbot user would like to send a message to another. Think of match-making chatbots, for example, or a delivery service chatbot where couriers would like to send updates to customers.
We’ll look into a simple example, using a TRIGGER block to establish two-way communication between different chatbot users – a regular user and a chatbot admin.
When a chatbot user wants to send a message to the admin (asking a question, for example), we’ll do a number of simple tasks:
- 1.Check if the admin is available (not engaged in conversation with another chatbot user already). If he’s not, we’ll send a message to the user and wait for a couple of minutes to try again.
- 2.If the admin is available, we’ll forward him/her the message from the chatbot user and wait for the response. Once the admin replies, we’ll forward the response to the original user.
Here’s the list of chatbot skills that we’ll use to achieve this (we’ll be triggering them for admin and for the user with the TRIGGER block):
- check_admin (triggered on admin’s side) – this skill will check if admin is available
- admin_delay (triggered on user’s side) – this skill will display the “Admin busy…” message to the user and wait before re-trying the check again
- ask_admin (triggered on admin’s side) – this skill will send the user’s message to the admin and wait for the admin’s response
- admin_answer (triggered on the user’s side) – this skill will display the admin’s reply to the user.
We’ll use the $admin_state attribute to track the current state of the chatbot admin – it will be either “busy” (if admin is unavailable or busy with another conversation) or “free”.
When the user wants to send a message to the chatbot admin, we’ll just start the “check_admin” skill for the user with admin’s ID:
Triggering “check_admin” skill on user’s request
Notice that the TRIGGER block allows us to send a number of parameters together with the “check_admin” event. These parameters will become attributes for the admin user, and we’ll be using them to send the user’s name, message, and ID.
Once this part is executed, the chatbot is set to idle for the user sending the message, but some action starts happening for the admin. Let’s look into it in detail.
First of all, we need to check if the admin is already answering a message from another user (the admin can only be talking to a single user at the moment). We’ll check the value of the $admin_state attribute and if it’s not “free”, we’ll send back the “admin_delay” event to originating user, starting a delay skill for him/her.
Otherwise, we’ll proceed to the “ask_admin” skill to wait for the admin’s response to the user’s question.
Sending the “admin_delay” event back to originating user
Notice the use of the $uid attribute – it was set by the TRIGGER block above and holds the messenger ID of the user who sent the message to the admin.
If the admin is already communicating with another chatbot user, we’ll notify the user about it and re-try sending the message in a couple of minutes. This is done in the “admin_delay” skill triggered in the previous step.
Delaying the delivery of user’s message if the admin is busy
Once the admin is available, we’ll forward the user’s message to him/her and wait for the response, and then deliver that response back to the originating user.
Waiting for the admin’s answer to the user’s question
We start this skill by setting the $admin_state attribute to “busy” so that if other users send messages to the admin while this skill is running, these messages will not interrupt it (due to the logic we implemented in the “check_admin” skill). Then we display a TEXT block, using attributes acquired from the TRIGGER block:
A question from $fname $lname ($uid): $message Type your answer below.This is how the message is composed
$fname, $lname, $uid, and $message attributes were set by the TRIGGER block from the initiating user in the “default” skill before:
Setting multiple attributes for another chatbot user before triggering the event
The result displayed to the admin will be something like this:
Example of the user’s message delivered to the chatbot admin
Once the message is displayed to the admin, the bot will use the LISTEN block to receive the response, and then trigger the “admin_answer” skill for the originating user to display that response.
Finally, we’ll set $admin_state back to “free” to make this skill available for other chatbot users.
Finally, let’s see how these two-way chatbot notifications can be displayed back to the user who started the conversation.
Displaying admin’s response to the user
We’re using some attributes here (set by the TRIGGER block from the admin’s side) to let the user know the name of the admin and what his/her response was.
So, with less than 30 blocks we managed to build a powerful two-way chatbot notifications mechanics, allowing any chatbot user to send questions to the admin and receive his/her answers.
With some imagination, you can easily upgrade this to allow even more features:
- multiple admins, assigned randomly or by user tags
- expanding the conversation to multiple messages from each side
- storing the conversation history in the Google Sheets
- etc
The sky is the limit with Activechat, so explore your options today!