Database trigger event

Database trigger events execute server-side when a specific change happens in the database, regardless of how the change was made.

This core reference entry is suited for advanced-level builders.

The database trigger event triggers whenever specific data is changes in the database. It is defined in the . Whenever a database thing of the specified type is modified, Bubble checks the "Only when..." of the event. If the condition returns a yes, the workflow runs.

  • You first set the Type of data on the event. This instructs Bubble what type to watch.

  • Then, use the Only when... field to set a for what kind of changes should trigger the event

Database trigger events are kicked off by any change to the data, regardless if the change is initiated by a workflow, an API call, or from manually editing the data in the editor.

User manual

Thing before change and thing now

When working with database trigger events, two unique data sources become available:

"Thing" will change to match the type of thing you are working with. You can reference these two data sources in the condition on the event itself, and in any actions within the database trigger event workflow.

If a thing is created or deleted

Triggers are also fired when a thing is created or deleted.

Created

If a thing is created, its data source will return an empty value, since there is no former thing to refer to. To check whether a thing was created, you can use the condition Thing before change is empty.

Deleted

If a thing is deleted, its data source will return an empty value, since the change made to the thing was to remove it altogether. To check whether a thing was deleted, you can use the condition Thing now is empty.

Precautions

There are a few caveats and precautions you should be aware of when using trigger events.

Multiple changes in one workflow

If a modifies a thing , database trigger events will only triggers once:

  • Thing before change will reflect the data in the thing before any changes were made, and Thing now will reflect the data in the thing after the last change has happened.

Privacy rules

The following guidelines are important to note regarding :

  • You can refer the Current user in an action in the database trigger event workflow

  • Unlike other workflows, database trigger events run with full administrative privileges

    • This means privacy rules are not applied to any actions and expressions within that workflow

    • Searches performed within the workflow will return all results, not just the results the current user is allowed to see

Triggers cannot kick of other triggers

A database event trigger cannot kick off a second triggers:

  • if data is modified by a workflow initiated by a trigger, Bubble does not check to see if those modifications are eligible for initiating other trigger events.

  • You can get around this by scheduling a separate custom event or API workflow from the original database trigger event workflow. Any database change made by this second workflow will trigger as expected.

    • This method will consume more workload

    • Also, while sometimes necessary, it should be used with caution, since it can easily set up a cascade or loop of workflows that can spend significant resources and possible lead to data corruption

Data source availability

The Only when... condition can only use and instead of the full list of Bubble data sources. The full list of data sources are available in the actions kicked off by the trigger.

A note on workload: keep in mind that workflows kicked off by triggers consume server capacity, like any other Bubble workflow. If your application kicks off multiple trigger workflows every time data is modified, this can add up to a lot of overhead to the total capacity used by your application.

To control this, use strict Only when... conditions to make sure you are only running trigger workflows when you need to. Article series: Pricing and workload

Note: If you have more than 20 database triggers that kick off at once, the remaining triggers will be to protect your app's infrastructure from consuming too much memory.

Event name

Enter the name of the .

Type of thing

A database trigger event watches a certain for . Define the type here.

Timezone selection

Override the backend trigger's timezone by setting an alternative timezone with a static or dynamic choice. For this setting to be available you must first enable the setting Enable timezone override controls in your app's general settings.

Last updated

#829: Flusk: more detailed Issue Descriptions

Change request updated