How workflows run

A workflow is a function: inputs in, actions execute, outputs back.

You click a button, and something happens. A row gets created. An email goes out. The page shows a confirmation. A workflow ran.

In the editor, workflows look like a list of actions. Underneath, the engine treats each one as a function - inputs come in from the page, actions execute, outputs flow back. This lesson opens up that function.

Browser
Page
Input · name
Acme Co
Dropdown · state
Active
Result
—
Bubble
Workflow
  1. 1.Set custom state
  2. 2.Hide loading spinner
  3. 3.Log analyticsAPI
  4. 4.Create a new Notification
  5. 5.Send notificationAPI
  6. 6.Show confirmation
A workflow, from click to render.

Inputs and outputs

Every workflow follows the same form. It takes a set of inputs, which are the client-side values that the workflow or its actions reference. That could be the value of an input, the contents of a custom state, the current cell of a repeating group. Then it does work and returns the outputs to the user. At the moment, each step's result is returned in full to the client. Keep this in mind when using external APIs where you don't want all results to be available to a technical user.

Collecting dependencies

When the trigger fires (e.g. a button being clicked), the Bubble engine calculates the dependencies of the workflow. In other words - what information do we need to send to this workflow to allow it to evaluate correctly? It sees what each action references, and resolves them.

The result is a payload it can send to Bubble that includes the current page context and any client-side values the workflow depends on. It's a bundle of the values the workflow needs, frozen at the moment it's triggered. This is important from a security standpoint: the simplest way to manipulate client-side values being sent to a workflow is to modify the request payload sent to it.

Running the actions

Now that Bubble has the context it needs, it can run the actions. Where possible, it runs actions as soon as it can - which may not necessarily be sequentially. API calls tend to run sequentially. Custom events can be used to force sequential execution, but the vast majority of the time this isn't necessary.

Returning results

Once the workflow is complete, the results of each action are returned in the response. You can see this yourself in the network tab of the browser. API calls include their full response - something to keep in mind from a security standpoint. This lets the engine re-render anything it needs to.