Backend events
This section covers backend events, which are events that trigger on Bubble's server
Last updated
Was this helpful?
This section covers backend events, which are events that trigger on Bubble's server
Last updated
Was this helpful?
Backend events are the triggers that happen on Bubble's server. They can be triggered by a few different conditions:
They can be scheduled to trigger at a specific time with the Schedule an API workflow action
They can be triggered by an API call from an external app
They can trigger as a response to a change in the database
They can be set to run at a specific interval
Backend events are handled completely by Bubble's server, and does not involve the user's device at all, whereas a frontend event will be passed from the user's device to the server.
This has a few implications, the most important being that they are always accessible. A page will stop doing any work as soon as it's closed, but the server is available 24/7.
Frontend events are the triggers that happen on a page. It's often – but not always – initiated by a user. Frontend events will only trigger as long as the page is open.
Frontend events can still lead to actions happening on the server – but the event (or trigger) happens on the page.
You can schedule a backend event to trigger at a specific time. This is a part of the and is done in the following away:
In the backend editor, create a new that contains all the actions that you need to perform
Use the Schedule API Workflow to set the workflow to run at a specific time.
Note that the scheduling is not the event – the event happens when the workflow is triggered at the specified time. As such, the scheduling can happen both on the frontend and the backend, but the event will happen on the backend. As such it's available even if the user closes your app.
By using the Bubble Workflow API you can also trigger a workflow from an external application. To do this:
Create an API Workflow in the backend editor, and make sure that Expose as a public API workflow is checked
Set up the external application to send a request to the workflow's endpoint
You can set up an event in the backend to start running a workflow whenever something specific is changed in the database by using . For example, let's say you are running an eCommerce app and you want to send an email whenever a data type called Order has a field called Completed purchase set to yes.
By combining a Database trigger event with an , you can specify exactly what kind of changes you want the event to respond to and run a workflow accordingly.
Create a Database trigger event in the backend editor
Specify the conditions for the trigger in the Only when field
There are two ways you can set up workflows to run at an interval such as once per day/week/month:
are events that are built specifically to trigger:
Daily
Weekly
Monthly
Quarterly
Yearly
They consist of two parts:
The recurring event, which contains the workflow to run and the database thing to run it on
The action Set/Cancel a recurring event which runs the first instance of the workflow and instructs Bubble at what frequency it should run.
Recursive workflows are workflows that re-schedule themselves by using the Schedule API workflow as an action and picking the same workflow as the one that contains the action. Since you can set a dynamic time to schedule the next cycle, this gives you a way to set an interval freely.
Recursive workflows are a bit more complicated to set up, but offer more flexibility than Recurring events and are available on lower-tier plans.
Using recursive workflows can potentially lead to infinite recursion, resulting in significant workload unit (WU) consumption. Starting on July 1st, 2024, Bubble will apply a default setting to terminate recursive workflow chains at 10 iterations for all new apps.
This means you need to either disable this feature or set a higher limit (recommended) if you plan to use recursion, or else any recursive workflow chain will be terminated after 10 iterations.
Some backend workflows allow you to override the Current user's current timezone by setting an alternative timezone with a static or dynamic choice. In practice, the timezone replacement works as following:
API Workflows: override the time zone of the API request
Recurring event: override the time zone in which the recurring event was first scheduled
Database trigger event: Override the time zone in which the change happened (i.e. the user's timezone when the change was made)
This helps you standardize the way in which your app parses and stores data. For example:
if you parse 1/1/2000 from Eastern Time and keep the default setting, Bubble will save that date as 1/1/2000 12:00 AM Eastern Time
If you instead override the client timezone with Pacific Time, selecting 1/1/2000 will save 1/1/2000 12:00 AM Pacific Time
This type of timezone standardization is useful in different scenarios:
Where an external API request includes a timestamp, but not a timezone: you can set a static or dynamic timezone when that call is received to ensure its properly parsed
Apps that deal with scheduling where the timezone of the scheduled appointment needs to remain constant: for example, if a user books a conference in London from Tokyo, your app can ensure that the timezone used is indeed London and not Tokyo.
Article: (start here if you are unfamiliar with the Workflow API)
Article:
Article:
Article:
Page:
Article:
Article:
Reference:
Reference:
Reference:
Article: Article: Article: