Comment on page
This section covers backend events, which are events that trigger on Bubble's server
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 Bubble Workflow API and is done in the following away:
- 1.In the backend editor, create a new API Workflow that contains all the actions that you need to perform
- 2.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 Database trigger events. 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 expression, you can specify exactly what kind of changes you want the event to respond to and run a workflow accordingly.
- 1.Create a Database trigger event in the backend editor
- 2.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:
Recurring events are events that are built specifically to trigger:
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.
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.