Database triggers and how to use them

Database triggers are a way of setting off workflows automatically in the backend when something changes in your database. When you change an item of our chosen data type, Bubble checks the trigger’s condition to see if the workflow should run.

They’re handy when you want to modify a data type in different parts of your Bubble app.

You can create a database trigger once. It will automatically take care of the required actions — no need to duplicate the workflow.

Use cases include:

  • Workflows can be triggered when you modify data in the Data panel of the editor.

This feature is valuable. The fact we can reference both the old and new versions of the data entry is convenient.

When do they run?

When creating a new database trigger, we describe a data type and a field to be checked for updates. These two things work together to create a trigger.

When working with database triggers, you’ll need to be familiar with two data types:

  • The “Thing Before Change” is the data of the original thing.

The “Thing” is the data type of the trigger.

If a workflow modifies a thing multiple times, it will only fire triggers once.

Triggers are also activated when a thing is created or deleted. If it was created, “Thing Before Change is empty” would be true. And if it was deleted, “Thing Now is empty” will be valid.

Creating a database trigger

Database triggers are available for all paid plans on Bubble. However, they need to be enabled.

Go to Settings > API > Enable Workflow API and backend workflows to enable them.

Creating a database trigger in | NocodeAssistant

Then in the page selector dropdown in the upper left, you’ll see the “Back-end workflows” page, which includes new kinds of workflows, including database change triggers.

Everyday use cases

Many apps we’ve seen built by others have complicated logic. They have 20 or 30 workflows that trigger the same API workflow because they all need to share logic.

Using database trigger workflows, you can make your app more straightforward to maintain by deleting all those actions.

Updating the user’s slug when the user’s name is changed

You want to update the user’s slug whenever they update their name.

This is the perfect example of a database trigger because you have a “Thing before”, the user’s old name, and a “Thing now”, the user’s new name.

We can create a database trigger that will check the data type user and the field fullName.

Updating the user's slug with database triggers in Nocodeassistant
Update the slug with database triggers

No matter where we create the workflow to update the fullName of the User, this database trigger will keep a watch and automatically trigger when the name is changed.

Triggering an email when a new record is created

A database trigger can be fired when a new record is created in the database.In this case, the condition will be that the “Thing before” will be empty.

Triggering an email when a new record is created in NocodeAssistant
Send an email when a new record is created

The “Thing before” will be empty as it is a new record.

Scheduling a backend workflow when a new record is created

It is important to remember that a database trigger will not cause another database trigger to fire. So in case you update a data type, say Country when the State is updated. And you have another database trigger that should run whenever the Country table is updated. In this case, the second database trigger will not be executed.

Trigger api workflow with database trigger in NocodeAssistant
You can schedule backend workflow with database triggers

A workaround is to create a backend workflow to update the Country. Whenever a State is updated, the backend workflow will run to update the Country.

This will help then the database trigger for Country as well.

When should they not be used?

Database triggers have improved a lot since they were introduced. They are more reliable, and there is no reason not to use them.

That being said, there are some things to be considered.

Database triggers don’t follow the privacy rules you define for your application

Any searches performed during the workflow will return all results, not just the results the current user is allowed to see.

Don’t rely on privacy results to filter the results to prevent this. Instead, apply constraints and advanced filters.

A database trigger cannot trigger another database trigger

Suppose a workflow initiated by a trigger modifies data. In that case, Bubble will not start any subsequent triggers, even if those modifications are eligible for starting other trigger events.

You need to use “Thing Now” and “Thing Before Change”

You can only use “Thing Now” and “Thing Before Change” to define the “Only when…” condition. The complete list of data sources is available in the actions kicked off by the trigger.

If you need some help with your Bubble app or if you need a team of Bubble developers to build a Bubble app for you, reach out to me at You can also follow me on Twitter.



I help people bring their ideas to life with Bubble.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store