Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Discussing triggers, logic and actions
In this section we will cover the the three main components of an automation and how they are used together to create the automation processes your app requires.
Once you have created a new automation you will find a panel on the left hand side of the builder, listing steps that can be added, initially only the list of triggers, once this is picked you will be presented with a list of logic and action steps.
When a step is added to your automation you can configure it in the right panel of the builder. The various defined inputs of the step will be listed and previous step outputs can be used, as discussed later.
In the following pages we will cover the three step types:
Below is a quick overview of setting up a few steps as part of an automation.
Kicking off automations
Each automation must have a single trigger step, this is essentially a watcher - waiting for a particular condition to be met at which point the process will kick off.
Currently there are three main ways that an automation can be triggered:
Saving a row to a particular table
Deleting a row from a particular table
An external trigger in the form of a JSON Webhook
Triggers are internal to the Budibase system and therefore cannot easily be altered - if you have an idea for a good trigger then let us know on our main Github repo! It is also possible to create custom triggers using the external Webhook, create an external application that will trigger on your required conditions and target your Budibase Webhook!
Budibase automations gives you the ability to build your backend logic into your Budibase applications. Your apps need to be able to handle processes that would have previously needed to be carried out by hand, like sending emails when data is updated in a table or deleting records when a particular conditions are met. Automations can also be used for integrating with external platforms and services, for example if you already have web services that are deeply integrated into your processes then automations can be used to receive or send data automatically between the two systems.
Once configured your automation will run as part of your app in the Budibase hosting platform making this a backend process that will run at any time when triggered. We will also be supporting automations as part of our self-hosted offering once this is made available.
To get started with Automations click into the Automate tab in the builder, from here you will see the button to "Create new automation", this will ask you for a name for your automation - you're now ready to get started.
The next sections will cover the three major components of an automation, triggers, logic and actions. It will also cover the contextually aware inputs of the system, allowing chaining of the various automation steps together.
Performing tasks in automations
Actions are the core of automations, these can carry out updates on a table, call to an external service, send emails and so on. We have built our action system to be easily extensible so actions can be added to the system at any time! Your automation can have many actions, allowing you to perform many different tasks as part of a single trigger.
Below is a few examples of actions that exist today however there may be many more when you look in the builder, to get a full list install the builder and check it out!
Create row, this will create a new row in a specified table
Update row, can be used to update a row which was triggered upon
Delete row, delete a specified row from a table, like something that was triggered upon
Send an email, as it suggests, send an email based on the specified inputs
The real power in actions is the ability to make use of outputs from previous steps, how to do this will be covered in the contextual inputs section.
We welcome ideas for further action steps, in-fact our system has been designed around making the development and deployment of new actions easy! If you have an idea for a new automation action and would like to pass it along to us, or even have a go at developing it yourself, check out our Automations repo on Github!
Conditional and intermediate steps
Sometimes it is necessary for your automation to make decisions as part of the process, for example if you wanted to send an email to a customer when their order enters the shipped state then you would need a logical step to handle this. An automation can have as many logical steps as you require, if you wish to filter against multiple different outputs from previous steps then this can be done with multiple filters.
Currently there are two main ways that logic can be executed in an automation:
Filtering against a specified field, with a particular operator and value to compare against
Delay, waiting a period of milliseconds before continuing
Our filter currently can handle checking a single input value against a single, if the condition is not met then the automation will stop execution, if two separate paths are required then two different automations can be used.
Finalising your automation
The last step in creating your new automation is saving it with the Save Automation button on the right panel and preparing to activate it. All automations will start initially in a inactive state, meaning that they will not attempt to process anything until you are ready for them to do so.
To active an automation simply click the big play button just next to the Save Automation button, the automation will now be active in your builder.
You now have two options for testing your automation:
Trigger the automation using real data, for example writing a new row to the table which an automation has been configured to monitor
Using the Test Automation button that will appear in the right panel when an automation has been saved
The second option can be useful for testing automations that are designed to be used with a webhook as otherwise these can be difficult to test. Whichever option you choose you should notice that the actions which were requested have been executed, e.g. if there was a Create Row action in your automation this row should now exist.
If your automation does not run as expected then check that all input mustache syntax is valid and any filters put in place should pass.
Below is a video showing the testing of a very basic automation being activated and then tested.
Using previous step outputs in later steps
The real power in Budibase automations is the ability to make use of the outputs from previous steps later on. This can be as simple as using information about a newly saved row which the automation has triggered on or it could be the result of an external API call.
Throughout the system we have used the same mustache syntax when we allow an input to be based on current state and we have built a binding editor into the builder which will help build valid syntax.
The state of an automation will build up the further you move through it, this is made obvious by our binding editor as it adds all of the previous steps outputs onto the list of options that can be used. The values cannot and will not change throughout execution, once they have been set they are fixed, however if you wish to combine multiple steps outputs into a single output you can do something like:
Our binding editor will keep track of all of the outputs from previous steps but it will not have an understanding of the properties that exist as part of them. In the binding editor you will notice that some properties such as Record
will be listed as type object. These particular properties will require you to add the name of a property you wish to make use of - an example of this might be:
You have a table which holds a list of sales people, with a column for their email address called EmailAddress
An automation is created which triggers on the creation of a new sales person
You wish to send an email to the sales person to welcome them to the system, in which case you would bind to the {{ trigger.record }}
in your send email action and add the EmailAddress property yourself, so it appears as {{ trigger.record.EmailAddress }}
Below is a short video showing how the contextual bindings can be used in a basic automation.