I hoped this would happen !
@allenyang Of many changes happen during a short time, could we define a “delay” before the trigger runs ? so the Backend Workflow does not run as many times as the Thing get modified.
I hoped this would happen !
This is a seriously awesome update!!
@eli - This should be pretty broad, but give it a try and let us know if anything’s missing
@nicolas_dap - The way it should work now is that if workflow A has a few actions that make changes to a thing, the backend workflow should only trigger once for workflow A (caveat if you log the user out in the middle of it - then it’ll run twice)
Could this be used to create a type of log system where you create a system which tracks every change a user makes ( especially if you use auto binding)?
Im interested in participating here too!
This would be incredibly useful for one of my apps. I’ve actually held off on integrating an API because of the need you are addressing in this feature. You can count me in to beta test it if you want!
What I actually meant is :
If 5 different workflows change a Thing in less than 30 seconds (because different process going on or different users), is there a way to trigger only once the Backend Workflow and not 5 times ?
This is a very current use case. I already tried to build a kind of auto-scheduler with several backend worflows to avoid my apps to get over-loaded
idea > have a mode > Run this: After xx seconds ?
Will be this feature be bound optionally to privacy settings?
Also please beware of recursiveness when developing this feature. A workflow that changes a thing which triggers this server side workflow to change a thing which then triggers this server side workflow indefinitely. Rinse and repeat…
But you probably thought of this already, didn’t you?
@klaas.vanhoeck1 - yes, you theoretically could with this, but that will probably take a noticeable amount of capacity and you’ll also see an impact from having such a large database. However, if you’re tracking edits which are infrequent to, say, only 1 data type that’s particularly sensitive, this feature could work well for that
@nicolas_dap - in that case, I don’t believe we have special logic yet that would wait across different workflows; the wait is only for a given workflow for now
@mente12 - Could you clarify what you mean by “bound to privacy settings”? This is a very pertinent design decision that we’d like feedback on And yes, we should be dealing with the recursive scenario gracefully
Awesome feature coming up!
Will the trigger watch connected things? For example, if the invoice_line 1 amount is 10 and the invoice_line amount 2 is 20, the invoice total should do the math of all the invoices lines amounts getting a total of 30.
Also, when are you planning to deploy this? Is in the near future? Because I was thinking about switching workflows to API workflows but this feature could fit better.
Thanks a lot.
Btw what happens if I just save all the same information into the object. E.g. I have a form with all fields having the initial content driven from the thing. And the user doesnt modify anything and proceeds to next step. The workflow saves the thing (with same info).
Since bubble auto-updates the modified date on the thing, does it mean the database trigger will run in such a scenario?
I’m not at a stage to participate but this could be a very handy feature for the app I’m working on. Great work and looking forward to updates.
@ryanck If I’m understanding your setup correctly, a DB change trigger should work, if you have it watching the data type that has invoice_line
@gaurav Great question - let me check to make 100% sure…
Got confirmation that yes, currently in your situation the database trigger should fire. (If you don’t want this behavior you can create a condition on the workflow accordingly)
@allenyang I am looking to use this to run a workflow anytime a thing is deleted. If I set the action to only run when “current thing is empty” will that work?
Or will this workflow not even run when an item is deleted?
It should work as you suggest!
This is now in public beta: [Public Beta] Database change triggers