Backend Workflows
Your app must be on a paid Bubble plan to use Backend Workflows
Using backend workflows can be ideal and/or necessary in the following situations:
When you have long and complex workflows with a lot of actions
When you need to reuse the same workflow from different parts (pages/reusables) of the application
When you need to run a workflow on a list of things, (i.e., loop through a list)
When you need to schedule a workflow in the future (with the ability to cancel the workflow)
If you want your workflow to run asynchronously. Backend workflows run on Bubble's server, and any workflow on a standard Bubble page which schedules a Backend workflow won't need to wait for the entire (Backend) workflow to finish before moving on to the next step in the front-end workflow.
If you want to create a webhook - or endpoint - to allow other applications to send and receive data from your Bubble app.
For more information on Backend workflows, read Airdev's Bubble Development Guide and Bubble's Manual.
Pro tip: If you'd like to run backend workflows synchronously (in order in the WF) and receive a response to the workflow action, set up an API connector action that points at the backend Workflow's API. Note that any API token used in the API Connector action should not be passed in the URL, but in the headers, and it should be marked as "Hidden" so that it cannot be stolen by app users.
Our template comes with 7 Backend workflows in the following folders.
Verify
verify_send: This will create a new verify record in the database and send a code to the user via email or sms
verify_check: This endpoint is called when the user submits a code to verify their email or phone number. When run, Canvas will verify whether the code is valid and return true or false
verify_delete: Deletes a verify record 15 minutes after it has been created.
Emails
send_email_template: This workflow is a template action that can be copied and edited for new email template backend actions.
Canvas
check_app_location: Determines if this application's identifiers are correct.
record_registration: Used one time when the Canvas app is registered. It generates a private token which will be used for authentication between the two apps. Additionally, it re-generates the public token, since the public token used for this call was sent in the URL of the Canvas admin user's browser during the registration process.
update_usersnap - When you start a project with AirDev, we'll use this workflow to enable usersnap testing on your app so you can submit feedback in our client management portal.
Last updated