As 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 you set up a workflow in that button, 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. Just like that. Holy shit.

What you just set up was a front-end workflow. It runs when an event on the page asks for it. That could be the page load, a button click or any other event initiated by the user or some condition.

Workflows and the browser

So what happened here, from a technical perspective? Let’s dig into it. Don’t worry, it’s pretty easy stuff.

When a user visits your page, a javascript file is downloaded. This is the part of Bubble’s engine that lives in your browser. It’s responsible for making something happen when a user interacts with your app by clicking, editing, dragging and scrolling their way around in it. It can make some changes on its own, such as setting a state, running an animation, hiding/showing something on the page or navigating to another page. Everything that leads to any permanent changes – such as saving something in the database, requires communicating with the other part of the Bubble engine: the Bubble server.

The bridge between the two is your browser. Your browser is set up to understand Javascript, and whenever something in that code asks for the server to do something, the browser sends a request. The server performs whatever task is given, and returns the result to the browser, which shows the results on the screen. Easy peasy.

This all sounds good, but what if you want the server to perform a task without any user involvement? What happens if the user closes the window during an operation? Or if you need to perform a bigger task, like changing thousands of records?

This is where backend workflows come in.

How backend workflows are run

Backend workflows are tasks that you give the Bubble server that are running independently of things happening in the app itself. There are a few ways that a backend workflow can be executed:

Scheduling from the front-end

You can ask the Bubble server to schedule a backend workflow at some future time, or simply ask it to run it right away by scheduling it with no delay.

Scheduling on a list

Scheduling 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 that you provide. This is one way to loop backend workflows, but I recommend using Recursive Workflows, as they give a higher degree of control over the process and will not time out.

Repeating it at certain intervals

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.

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.

Using recursive workflows

A recursive workflow is a backend workflow that schedules itself. In other words, you can set it up to loop on a list or run at regular intervals.

Backend workflows vs front-end workflows

Bubble’s backend can be considered a separate zone from your front-end in many ways. You can run as many workflows as you like without users ever noticing any delays or performance degradation, as long as you stay within your app’s total capacity. The tasks will predictably run with no user interaction, and regardless of whether the user has closed the app tab or not.

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
  • 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:

  • 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
  • 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.

Useful articles and tips

Useful articles and tips

Join the mailing list to get guides, opinions and articles on Bubble, no-code, automation and the tech industry.

You have Successfully Subscribed!

Share This