Bubble is built around a workflow-based programming system. Create workflows to define how the app behaves when users interact with it. A workflow is composed of an event, which is what triggers the workflow and the series of actions that run. An example of a workflow is 'When the button Signup is clicked, sign the user up, send an email, and then change the page.' Workflows are specific to a page in the app and are modified in the Workflow Tab. If an action returns information, access this information as 'Result of previous step.' The section below provides information for all events and actions used in Bubble.
There are situations when you only want a workflow or action to run under specific circumstances. For example, when the user is logged in, when a checkbox is clicked, when the user's email contains a specific domain, etc. In this case, add a condition to the event. Build a logical condition using the Composer piece by piece. In the case of actions, if the condition isn't met, the workflow will skip that action. Any subsequent actions will run using empty data.
Note: When creating a workflow involving Rich Text, be careful when also using the "Text/Button ... is pressed" conditional statement on the same Rich Text - the two can interfere. As a workaround, consider adding a transparent shape on top and making that the source of the on click workflows.
Choose the element that the event/action applies to.
Assign a workflow/event to a folder for clarity in the app. Create a new folder by selecting the 'Create a new folder…' entry at the bottom of this dropdown menu or from the Workflow folders section in the Palette.
Tip: To display the workflow folders, from the Workflow Tab, click the arrow in the long vertical area to the right of the Tab section in the Palette.
Select a color for the event. This organizes workflows when the app becomes more complex. This color only appears in Development mode.
When using the debugger, instead of using the step-by-step mode for all workflows, specify specific events or actions that should pause. Checking this box allows this. This option has no effect on the app when the debugger isn't present. Similarly, when users are using the app, this will not be applied.
Occasionally, when debugging, you may want to disable a workflow without getting rid of it. This could allow you to test specific pieces of functionality without consequent workflows getting in the way, or to modify an existing workflow while keeping a copy of the version that is already working for future reference.