Trigger Event
Also known as a "database trigger event", this event is defined in the Backend Workflow section and runs workflows triggered by changes in the database.
Whenever an item of the given type is modified, we check the "Only when..." condition of the event, and if the condition passes, we run the workflow. This is useful for situations where a given piece of data could be modified by many different places in your application, and you want to make sure something happens each time the data is modified in a specific way. For instance, you could use this to sync the value of certain data types to an external API whenever the data is modified. 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.
When working with database trigger events, there are two special data types: "Thing Before Change" and "Thing Now" (where "Thing" will change to match the type of thing you are working with). "Thing Before Change" represents the data of the thing that was changed prior to the changes being made; "Thing Now" represents the current data. If a workflow modifies a thing multiple times, we only fire triggers once: "Thing Before Change" will be the data at the beginning of the workflow, and "New Thing" will be the data at the end. Triggers are also fired when a thing is created or deleted. If it was created, "Thing Before Change is empty" will be true, and if it was deleted "Thing Now is empty" will be true.
There are several caveats about using data triggers.
First, 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.
Second, triggers cannot kick off other triggers: if data is modified by a workflow initiated by a trigger, we do not check to see if those modifications are eligible for initiating other trigger events.
Third, the "Only when..." condition can only use "Thing Now" and "Thing Before Change" 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.
Finally, keep in mind that workflows kicked off by triggers consume 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.
Note: If you have more than 20 database triggers that kick off at once, the remaining triggers will be scheduled to protect your app's infrastructure from consuming too much memory.
Enter the name of the workflow.
A database trigger event watches a certain type of thing for changes. Define the type here.
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 modified 6mo ago