Virtual assistants are there to provide information and guidance for the user. The knowledge of the assistants is, however, limited to the conversation itself. When virtual assistants are incapable of providing the functionality or information the user expects, they need to consult another source of information.
Take the example of a conversation where a user asks the date of today. Since dates change every day, it would not be wise to go to your flow and write the date of the day on your map each day.
The date of the day cannot be deducted from the content of the conversation either.
In the end, without an Integration Action, virtual assistants would be incapable of answering the question. (or, again, you can have a conversation designer that updates the date of "today" each day in your map...but how sustainable would that be?)
Suppose that, as a human being, you cannot recall the date of today. How would you find it? You would probably google it to find out.
That's exactly what virtual assistants do with an Integration Action. The Integration Action finds the date and transfers the information to the chatbot for it to reply properly.
As a general rule of thumb:
then you probably need to use the Integration Action.
Here is a non-exclusive list of common cases where the Integration Action is used:
👉 Making mathematical calculations,
👉 Resetting the state of the assistant, i.e., clearing the parameters the assistant gathers throughout the conversation,
👉 Finding out something that pertains to the user, such as finding the user's order.
In a nutshell, the Integration Action works just like how any other link on the Internet works.
When you click on a link or enter the link in your browser (e.g. Chrome), the page loads with a bunch of information.
So, what happens here is that you request the web page for a resource, say a tweet, and the service that is located somewhere on the Internet responds to you with the actual tweet.
Let's delve into the Client-Server Model in more detail. It is the client that initiates the communication, and it is the server/service that fulfills the request and returns the information about the process or the result. For all this to work, the requester and the responder, i.e. the client and the server, need to understand each other.
There are predefined protocols for transmitting information between two parts, just as we have rules for using language.
So, what is left to us is to understand the basics of HTTP. If we go back to the tweet example, there are multiple actions that we might want to perform on a given tweet. We might simply want to get the content of the tweet. We might create a new tweet, edit it, or delete it. So we have at least two ingredients here:
Let's dive into what they mean:
The intent of our action, i.e., reading, creating, editing, or deleting a tweet, corresponds to what we refer to as the HTTP Method.
HTTP Method | When to Use | |
GET | When you want to get the information | |
POST | When you want to create a new resource | |
PATCH |
| |
DELETE | When you want to delete the resource |
In the tweet example, each HTTP Method would be:
The actual link on the Internet that we want to act on. For example, 'http://google.com'.
Okay, but where do you specify the method when you type out the URL on the browser and hit enter? The browser itself does that on your behalf. It always performs a GET request.
Long story short, when you need to use the Integration Action, you must follow the HTTP protocol. And just as explained above, at least two ingredients are needed to do so:
URL
You need to provide the URL, i.e., a link that starts with http://. Think of it as sending someone a letter. 📨 You will need an address that uniquely identifies the receiver so that the postal office will get to know where it needs to send the letter.
There is no way to predict the URL beforehand, thus you need to ask the developer who is responsible for creating the required service.
Method
You also need to specify the method. You need to get this information from the developer as well.
But now suppose that you want to create an order.
The method should be "POST" since you will be creating a new order. However, you need something additional to create an order, and those are the order details such as who ordered what.
For POST and PATCH methods, we need additional information.
Well, since your assistant cannot do this part by itself, what you need here is to ask the details in the assistant & forward that information to the Integration Action.
What we want here is to ask the user some questions, and then request the Integration Action to create the actual order by providing the user input.
Let's say that you need the user's name, surname, phone number, and shipping address to create a new order. The assistant needs to send these pieces of information to the Integration Action for it to create the order using the information given.
For example, you can add an input action with the following question:
You also need to name the parameter using the user interface that the Input Action provides. Let's say you write firstName
.
When the user answers your question, say, as John
, then firstName
will be assigned as John
.
For many Actions in MindBehind, you can use the pound/hash (#) symbol as a placeholder for the parameter. In this example, when the virtual assistant replied with a "Hello John! 👋" to the user, it is seen as "Hello #firstName! 👋" on the map.
You need to do a similar thing for the surname, phone number, and shipping address as well. Let's say that the parameter lastName
determines the surname, phoneNumber
determines the phone number, and shippingAddress
specifies the latter.
Some examples to name the parameters: nameOfTheDay (camelCase) name_of_the_day (snake_case) NameOfTheDay (PascaleCase)
Here, the Integration Action needs to know what you named the variable that corresponds to the user's phone number as well as the shipping address.
The developer and the conversation designer need to predetermine the names of the parameters and their meanings beforehand so that they both know where to look when exchanging information.
This is also true when it is time for the Integration Action to return to the assistant. The virtual assistant might want to know the ID of the order, and whether it was successfully created or not. So, again, the developer and the designer need to determine the names of these variables.
Flow