Data triggers
Guidelines for use of Bubble's new data triggers, released for a public beta in March 2020
This page will serve as a guide for Bubble's new data trigger actions - actions in the Backend Workflows page that will happen any time you make changes to a data object anywhere in the app. For example, when you add an object to a Cart, a data trigger workflow can automatically re-calculate taxes and any other calculated fields, eliminating the need to copy logic to many places throughout the app.
Before starting this guide, be aware that it is best to wait at least a few weeks after a feature like this is released before including it for mission-critical features in a client app. Since it was only just released as a public beta, it is possible that the feature is not yet production-ready or that some bugs will be found in the following weeks.
For all of the below use cases, they're really only relevant if a data type is being changed in more than one place in your Bubble app. If you're considering moving workflows to a data trigger, and the trigger is only run from one place in the app, it's best to stick to normal workflows.
Updating one object when another directly related object is changed.
For example: a taxi Driver has a Car in a ride-sharing app. When the Car is updated, say if a car becomes too old to be eligible for the app, the Driver can also be updated - in this case, to be unavailable for future rides.
Data can be linked in many different ways, including:
- Bidirectional linkages (like the above Driver example)
- Data from one object is directly linked to another, and vice versa
- One-to-one linkages for CSV exports
- Data from one object is directly linked to another, and you want to replicate saved data in order to more easily export it as one table.
- Imagine that in a Bubble app, each User has a Store, and each Store has a
monthly revenue. In a data export of Users, normally the only field included from the Store would be the Store's unique ID. We can include each User's Store'smonthly revenueon a secondmonthly revenuefield on the User object. That field will also be included in the CSV export. However, the User'smonthly revenuefield will also need to be updated each time the Store'smonthly revenuefield changes. Using a data trigger here would make since if a User can make changes to a Store's name in multiple places in the app.
Fields made for CSV export could benefit from data triggers
- Roll-up/summarized data
- Imagine that there is a Repeating Group of Users and their number of Items is displayed as a column in the UI. Rather than using a
do a search for Items:countcall in each row and calculating the number of items, a number field named Item Count can be recalculated each time an item is added/removed. Again, this makes most sense if the number of items can be changed in many places in the app. If it is only changed in one workflow, you can add the step to save the number of items on the User object inside that same workflow.
Running complex calculations that need to be updated whenever a field is changed.
For example: financial calculations, or any formula containing many factors, where the result should be stored as a field.
Note the conditions here - if the calculations are already updated, there is no need to write to the database.
The second step takes the results of step 1 and combines them in a way that would be difficult to build and difficult to understand with Bubble mathematical logic.
Re-generating a field that reformats information from other fields. This is similar to the calculations, but generates a text output instead of a number output.
For example: a JSON that represents an object and contains each of the other fields, but is stored as a text.
This User JSON can be used to manipulate User data on the page with Javascript, among other things.
Overusing this feature can have huge impacts on app performance. Completing actions that take up a lot of capacity are not recommended, such as making changes to a list of many things.
Additionally, searches for data that are completed here do NOT have restrictions with privacy rules. Any search that is completed here can return an entire table in the database if it's not set up correctly, potentially using up your app's capacity and slowing it down drastically.
- User-specific info:
- Logging out of a User's account (using the Bubble "Log a user out" workflow) activates any User data trigger.
- Logging into a User's account doesn't activate a User data trigger.
- Signing up as a new User activates a User data trigger.
- One data trigger can't trigger another data trigger - if I edit a User's Post's in a User data trigger, Post data triggers will not be activated.
- Workaround: schedule an API workflow that makes changes to an object. This will trigger the data trigger for that object. (Functional as of May 13, 2020.)
- There seems to be a protection against infinite loops here. If a User is modified in your app and the User trigger is activated, which then edits a Post in an API workflow, then the Post data trigger will then be triggered. However, if you then edit the User object in an API workflow triggered from the Post data trigger workflow, the User data trigger won't be activated, preventing a loop of User->Post->User->Post from continually firing.
Last modified 1yr ago