What are Database Triggers in Bubble 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 modifying 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.
• Workflows can be triggered when data is changed through the Data API.
• Implementing a "Schedule API workflow" that will run every time a specific type of modification is made to your data

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 Now" is the current data.

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.

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 to check the data type user and the field fullName.

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 this case, the condition will be that the "Thing before" will be empty.

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, another database trigger should run whenever the Country table is updated.

In this case, the second database trigger will not be executed.

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 can 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 a team of Bubble developers to build a Bubble app for you, reach out to me at himanshu@nocodeassistant.com. You can also follow me on Twitter.