Summary
Botdoc Automations are designed to perform automated calls to the API endpoints itself based on custom triggers that can be set on in the Automation configuration.
In order to use Automations, you still need to have a comprehensive understanding of how the API works, as in order to configure Automations and, the flows you can create with it.
When working with Automations, you should be familiar with its 3 components, ; those are:
Automation Group: Defines a group of ordered Automation(s) (or so-called actions) to be performed.
Automations: Defines a single action to perform.
Triggers: Defines “when” the AutomationGroup should be executed according to the available Triggers created.
Context
Automations have Automation has its own context. Each Automation (step) and Trigger exports a different set of variables in order to be used between each of the steps as needed. This is important as in most of the scenarios, you will need data from the creation of a Container in order to associate a Recipient to that Container and so forth. The context gets updated after the execution of each step, containing new data returned by the current step being executed. The context available in a the current step being created is all of the previous steps and the trigger variables. Trigger variables are defined by the trigger type being used. See tables below to understand the variables available in each of the trigger types.
...
This trigger creates a unique URL of which when opened by someone, it will try to open the native SMS app on the users phone with a default message. This trigger will then wait for a text message with the reference # created by the trigger in order to execute the Automation Group this trigger is associated with. The reference numbers created by this trigger does do expire, ; this means the time between opening the URL and sending the message should NOT surpass 10 exceed10 minutes, ; otherwise the reference # created for that trigger is expired and won’t trigger the Automation Group.
...
First, login to your developer portal and navigate to “Automations => Automations”. In On this page you should see a list of all Automation Groups created for the selected Apikey. Click on the plus button in order to add a new Automation Group. You should see the following screen. In this first step you need to enter a name and click save.
...
Once saved, the page will allow you to make additional changes to the page, such as adding Triggers and Steps.
...
Create a Trigger
First The first step now is to create a Trigger, that is defining defines when this Automation Group will be executed. Click on the “Select a trigger to add”, choose the type of trigger you want and click ADD. In this case we will choose Inbound Text from the URL Trigger.
Here, we gave a Label to the trigger, a slug, a default message that is the message that will be pre-filled on the user mobile and, selected the number we expect a message back from the pool of numbers available. (The URL trigger is only shown after you save the trigger)
This trigger as its configured will open the Message application on the mobile device once the Mobile device visits the page that is configured under URL trigger, with a pre-filled body of “Hello there, I need to send my documents to you” to the number selected under “Inbound number”.
...
We could still add more query arguments to the URL before actually giving it to someone. For example, let’s say we want to distribute this URL to the State but, we want to know the City that URL was opened. We could in this case send the URL
...
to the people in Denver. This small change will cause the associated variables to for the trigger to change. The context for the URL opened from Aurora would looks look like:
| Code Block |
|---|
{
"trigger": {
"trigger1": {
"origin": <number from whom sent the message>,
"remote_addr": <ip address of who opened the url>,
"reference": <reference created by the trigger number>,
"city": "Aurora"
}
}
} |
While for the people who opens open the URL from Denver, it would looks look like:
| Code Block |
|---|
{
"trigger": {
"trigger1": {
"origin": <number from whom sent the message>,
"remote_addr": <ip address of who opened the url>,
"reference": <reference created by the trigger number>,
"city": "Denver"
}
}
} |
A word of caution. : You should NOT use the reference # generated by a trigger as a unique id. This reference is randomly generated, and its uniqueness is not defined by its value only.
...
Create a P2 Container
Create a default message inside that P2 Container saying “Hello there, to ! To get started, enter your full name”
Create a Recipient for that Container
Create a RecipientItem for the step 3 Recipient created with the mobile number we received the text from
Create a ContainerMetadata to this Container with the City
Send the Container
...
Now, we will move forward and create a Message into in that Container, in order to do so we add a new step and:
...
According to our API documentation, when creating a Message, I must also provide also what is the Container I want to associate that message to. That is another usage of the Context. As the creation of the Container comes prior to the creation of the Message, the data returned by the endpoint for creating a Container in step 1 is available for use in step 2. This is valid for all steps through the whole set of steps defined in the Automation Group, ; any data returned on a prior step will be available on the current step accessing the Context variables.
...
As the step 2, in order to create a Recipient we need to know what Container it belongs to, ; therefore we access our Context data in order to get the container id created on step 1.
...
Now we need to associate a RecipientItem to the Container. Thats That's how and where we will send that container. As we are using the Inbound Text from URL Trigger, the users mobile number is available to us in the Context. So, we will pull that number and, send as a text message.
...
We are almost done, we just need to grab the Query Argument in the URL “city” and associate that with the Container as ContainerMetadata, so when you pull the Container information from our endpoint, you will know the City of the User that created that Container, for example.
...
Send the Container
...
This concludes a very simple Automation flow that will send a Container to a user that opens the URL of the trigger and, start starts a conversation. From here, there are thousands of different flows and use cases that are possible. As soon as the container is sent and opened, our API triggers several Webhooks to the provided URL (if this would have a callback, it would be in the Container definition on in step 1). From there you can automatically pop notifications and, start conversations from with in your integration with us.
...