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 API Workflows, we first have to understand the back-end 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 front-end 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 back-end workflows come in.
How back-end workflows work
Back-end workflows, labelled some places as API workflows (they’re the same thing) 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?
Bubble’s front-end is optimized in different ways for running workflows on the page instead of the back-end. 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
Back-end 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.
Triggering back-end workflows
There are 5 different ways in which you can trigger Bubble to run a back-end 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 back-end 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 back-end 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
The first part is a basic recursive workflow guide, and the second part shows you how to measure the progress of a recursive workflows.