Backend Workflows in Bubble is the workhorse of your app. Whenever you need to work on big amounts of data or schedule workflows to run in the future or even repeatedly, you’ll need the Schedule API Workflow action. The name of it makes it sound pretty complicated, but it’s actually easy stuff.
To understand Bubble Backend Workflows, we first have to understand the backend in general.
If you’re a new Bubble developer, it’s likely that most of your focus is on the user interface and functionality of your app. When a user clicks the save button in a form, something ought to happen, right?
So using the workflow editor, you set up an action to trigger when that button is clicked, and at some point in the past, you probably felt that tingling sensation of power when you discovered that you could write to a database and display the changes on the screen. Just like that. Holy shit.
What you just set up was a frontend workflow. It runs whenever a trigger on the current page asks for it (like the User clicking a button), and it can perform all sorts of actions. But what happens when the User navigates away from your app? As soon as the page is closed, no more workflows will run.
This is where backend workflows come in.
How backend workflows work
Accessing the Backend Workflow editor
To access the Backend Workflow editor in your Bubble app, you first need to activate the feature in your app’s API settings as illustrated below:
When the box is checked, you’ll find a new option in your app’s Page selector:
Understanding Backend Workflows
Backend workflows do not happen in the User’s browser, but on Bubble’s server. They can be triggered from the browser, but they will finish on the server regardless of what actions the User takes after they’ve been scheduled. No matter how heavy a workload they perform, it won’t slow down the app experience for the User unless it maxes out the available capacity on the server.
Backend workflows are your best, and in many cases only, option when you want to process big amounts of data. In the front-end, Make changes on a list is really the only way you can do that. In the backend you can ask Bubble to make changes on one data record, and then move on to the next in a potentially infinite loop.
So if backend workflows can handle an infinite number of records and run without affecting performance, should all workflows be run in the backend?
No.
Bubble’s front-end is optimized in different ways for running workflows on the page instead of the backend. Some of them are key to building a user-friendly user interface.
Front-end workflows are optimized for:
- Making changes to one or a few Things (up to a hundred – give or take)
- Showing the results of a process immediately on the screen
- Giving you as a developer a high degree of control over when an action or workflow is finished
Backend workflows are optimized for:
- Scheduling a workflow to run later or repeatedly
- Process a larger number of Things
- Running processes that you don’t want to slow the app down, and optimally that don’t need to be completed immediately (that could sometimes be running for hours or even days to complete)
- Workflows that don’t require any user interaction
- Cascading workflows (where one action leads to triggering a lot of other actions)
Backend workflows are a fantastic tool for specific tasks, but are not right for every scenario. Use them when you want your server to do some of the heavy loading in database maintenance. Don’t rely on them for small changes where your users want to see immediate results.
What’s the difference between an API workflow and a Backend Workflow in Bubble?
Anything that you edit in the Backend Workflows editor (whether it’s an API Workflow, a Custom workflow, a Backend Trigger Event or a Recurring Event) is a Backend Workflow. API Workflows are workflows that can be triggered by an API request (either internally in your own app or from an outside client). They get their own API Endpoint URL and you can decide what kind of authorization and Privacy Rule protection you want to apply to them.
In that sense, an API Workflow is a Backend Workflow, but a Backend Workflow is not necessarily an API workflow. Check out this article, if you want to learn more about how API’s work in Bubble.
Triggering backend workflows
There are 5 different ways in which you can trigger Bubble to run a Backend Workflow:
Schedule an API Workflow
Using the Schedule API Workflow you can tell Bubble to run it immediately or at any point in the future. This is useful in all sorts of scenarios: let’s say you want to email a User a welcome email 30 minutes after they sign up for example. Simply tell Bubble to send that email at the Current date/time+minutes:30 and half an hour later that email will land in the User’s inbox, even if they closed their browser window in the meantime.
Schedule API Workflow on a list
Schedule API Workflow on a List works very much in the same way as regular scheduling, except that you’re asking Bubble to repeat the Backend Workflow on every item in a list of Things that you provide. It’s easy to think of this as a loop, but that’s not technically how it works – actually Bubble schedules one independent workflow at a specified time for each of the items in the list you provide, and once scheduled, they run completely independently of each other.
In other words, let’s say you schedule workflows on 300 items with a 1 second delay, Bubble will not wait until one is finished and then execute the next one one second later: rather it will schedule all of them one second after the other for exactly 300 seconds, independently of how long one takes to process.
In most cases, using recursive workflows (see separate point below) gives a higher degree of control over running workflows on lots of things, and I recommend you check it out.
Triggering recurring Events
You can also ask Bubble to repeat a workflow at a certain time interval, such as once per week. How often you can schedule a repeating workflow depends on your Bubble plan. While the workflow type still works, I personally find this to be deprecated since Bubble opened up the use of Recursive Workflows (that offer a lot more flexibility).
Using a backend trigger
Backend Triggers are rules you give the server to watch for changes in the database. For example, You may want to trigger a workflow whenever the First name of a User is changed. This will instruct Bubble to keep an eye out for changes made to that field on any User, and then execute a workflow whenever it detects something. Just like other backend workflows, this will happen even if the User closes the app window, or even if you change something directly in the Bubble database.
We have a guide to using backend triggers in Bubble that includes any caveats and pitfalls you might encounter.
Using recursive workflows
A recursive workflow is a backend workflow that schedules itself one or more times after the original run. In other words, you can set it up to loop on a list or run at flexible intervals. Note that this is not a Bubble feature per se, but a method that you yourself set up by using the Schedule API workflow feature to re-schedule its own workflow. This will allow a workflow to loop indefinitely or until a specific condition is met
If you’re interested, we have a multi-part guide on Recursive workflows: The first part is a basic recursive workflow guide, and the second part shows you how to measure the progress of a recursive workflows.
