I’m excited to announce that database change triggers are open for public beta testing. They are available on (non-legacy) Person plans and above. If your app is eligible for them, then on the Backend workflows page, you will see:
Special thanks to @anna4, who built out the core of the feature during an internship with us this winter! And thank you to everyone who helped with alpha testing.
Database triggers allow triggering backend workflows when data in your app is modified according to rules you express in the “Only when…” condition. Use cases include:
Triggering a workflow when you modify data in the Data panel of the editor
Triggering a workflow when you modify data via the Data API
Centralizing logic that should happen whenever a certain type of modification is made, to avoid having to manually add a “Schedule API workflow” action in every single workflow in your app that touches that data
I’m particularly excited about that last use case. Lots of apps we see have complicated logic where 20 or 30 workflows are all triggering the same API workflow, because they all need to share logic. Using change trigger workflows, you can make your app a lot simpler and easier to maintain by deleting all those actions.
This feature is in public beta, which means that while we’ve tested it in real apps, do expect to see bugs that have slipped through our testing. Test carefully before depending on it for a mission critical use case. As always, please report bugs here: https://bubble.io/bug_report
There are a number of details, caveats and limitations, so I recommend reading the full documentation before using it: Trigger Event - Bubble Docs
Is this to say we can implement Excel like functionality? Say I have a simple shopping cart example… if the quantity in cart changes, then trigger this workflow to update the total price to equal the new quantity * price?
… but also it could be way more complicated than that.?. like I could instead trigger an API call that does a really fancy computation for me and returns the result to be saved to the database… all from the backend?
Love this feature, @josh! Tons of use cases for it and have been experimenting.
A tip for anyone who may not know about it (or forgot about it), use the App Search tool to go through any endpoint you want to convert to a trigger and find each place in your app where you are scheduling that endpoint.
Agreed, this feature is proving super handy and the fact we can reference both the old and new version of the data entry is really useful. Great job guys on this one.
@shu.teopengco The short answer is yes, this would make the perfect companion to achieve such a feature like an activity, notification or change log system.
I was wondering if someone could answer my question on a use case.
I have a user thing with nested things inside
So when it comes to downloading the data into one CSV file, what I do is I keep a mirrored thing and I update that with workflows everytime something is changed. Hope your with me.
I’ve been wondering if this Database change trigger is a good use case for above instead of using workflows every time I change a dropdown? I’ve been trying to work out how to use it but I’m struggling a little bit.
This is an amazing and excellent feature which saves a lot of flows and condition of logic running in parallel sometimes we can get very easily lost, thank you.
A small & useful upgrade would be to output a difference between the new thing and the existing thing. This would be really powerful for audit logging.
Finally a selective ‘do not fire change’ check box since there will be workflows running where you do not want it to trigger a database update.
I also said that it’s value for money! I’ll never argue that point if anything Bubble is too cheap!
But withholding features from your earliest adopter plans creates a lack in confidence not only for existing users but more importantly for new users looking to adopt the platform.
I am a massive Bubble advocate but the biggest push back that I get when I try to encourage users to the platform is not the price, the value or the learning curve… it’s the fear of being trapped on a platform where they have zero control over potential future costs!
Forcing users to increase their app costs (regardless of whether it’s $1 or $1,000) will further heighten that apprehension and as such reduce adoption to the platform.
One of Bubbles best policies is that if it goes out of business it will open source which allows us all to build on the platform with confidence. Not that I can see bubble ever going out of business (I’d buy shares if I could!).
The second thing that would make a massive difference is a similar statement surrounding price and legacy users! Give people an incentive to build earlier rather than later!
For the record I have no issues with the later plans having increased capacity etc but restricting features from legacy plans is quite frankly short sighted because even if it reduces confidence in the platform by 1% then whoever made that decision is not doing this wonderful and amazing platform justice!
Just to make it more UI friendly!
