Database trigger events
This section covers database trigger events, which are events that trigger whenever some specific data in the database changes
Last updated
This section covers database trigger events, which are events that trigger whenever some specific data in the database changes
Last updated
Database trigger events are a type of that trigger whenever some specific data in the database changes. What this means is that whenever something is created, changed or deleted, the event will trigger.
By combining this event with a dynamic expression, you can specify exactly what kind of change you want the event to be watching.
We'll use the following example in this walkthrough: we want to set up a trigger that watches for whenever any user changes their email address and perform an action whenever that happens.
Database trigger events are a part of Bubble' , which means that the first step in setting them up is to . From there, you click the + symbol to add a workflow, and select A thing is modified event.
As soon as the database trigger event has been created, Bubble will display the settings for that event:
In the Type field, we need to pick what data type we want the event to be watching. Since we want the event to trigger whenever a user changes their email, we'll set it to User.
The next step is to build the ; this is the part that tells Bubble what kind of change we want the event to respond to.
While structurally similar to expressions used elsewhere, expressions used in database trigger events are different in that they only give you access to two :
Thing before change
Thing after change
In our example, the two data sources would represent the following data:
The user before the data in the database was changed
The user after the data in the database was changed
In other words; the event is responding to a change on the user, and it gives us access to the user in question both before and after that change has taken place – all in the same workflow. What does that mean to our expression? It means that we can two values: one from before the user was changed, and one from after.
This is how we build the expression to tell Bubble what kind of data to watch: by checking if the email saved on the user before the change is the same as the user after the change: If not, the workflow triggers.
This is what the expression should look like:
In this expression, the User before change/User after change are both data sources, email are operators and is not is the comparison.
Database trigger events look at any change to a data type, and triggers the event if one takes place. Bubble then checks the Only when expression and stops the rest of the workflow from running if it returns a negative value (no).
This is useful to know for a couple of reasons:
A database trigger event without an Only when expression will run on every single change made to that data type
Setting up a lot of database trigger events without any conditions for running can end up spending more capacity than you intended – exercise care when using and use expressions to stop unneeded workflows from running
Database trigger events come with some built-in limitations:
Although you can use "Current User" to see which user, if any, initiated the workflow that changed the thing, trigger workflows run with full administrative privileges and privacy roles are not applied while the trigger is running, so any searches performed during the workflow will return all results, not just the results the current user is allowed to see.
If a database trigger has an action that makes changes to a thing, that change will not trigger a second trigger event (including the same trigger event). This could lead to an eternal loop of triggers. If you want to ensure that workflows started by a database trigger events do trigger secondary events, you can move the actions into an API workflow and schedule that workflow from the trigger workflow.
If you have a workflow that contains multiple actions that should trigger the event, it will only fire once for that workflow.
