I have a custom workflow that needs the updated value from the database that is linked to the autobind in order to calculate correctly, so it is vital that the autobind updates the database BEFORE the custom workflow (on “an input’s value is changed”) runs.
We’ve done a lot with timing logic and my best guess is that autobind should work faster, on average, than the database lookup, but it’s probably not guaranteed to always be first. As such, the timing would probably work out 95 to 99.9% of the time, but not 100%. Just my educated guess though.
In theory, adding a short pause between the two will increase the likelihood that the first one finishes first. That said, I believe the “add a pause” only pauses items on the front-end and doesn’t change database writes, etc. I could be wrong around this 2nd part though.
The only way to really know for sure whether a pause is needed or how much of pause is to actually run it a bunch of times and keep track of how often the 1st step finishes before the 2nd. One thing we’ve learned from experience is that flows that work under normal load with a very high degree of frequency sometimes break down when the server is under load. In other words, the server’s behavior changes when it’s at max capacity so if it’s something critical it may be worth trying to find a way to test with a server that’s at capacity.
Adding another workflow to run as you’re talking about is usually a good solution in my experience. I’d start with that approach unless you seem some other reason not to. I can imagine many scenarios where that would be more than sufficient.
I should mention if you wanted to keep an input field in sync with the database, you could also run a workflow to update the database anytime the field is no longer focused (or similar). As part of this, you could have the workflow run 2 actions and put a pause between them which, I believe, Bubble interprets to mean you want the actions run in series and not in parallel. I don’t know whether this solution would make sense for your scenario, but figured I’d mention it in case it’s helpful.
you have to copy/paste this expression from the DESIGN panel (you can’t access it from the workflow and “buyer beware” this may break in the future as I’ve heard that it isn’t “officially supported”. But credit to @petter who is a god to me now for teaching me this. (P.S. don’t use “this input” but the actual name of the input)
Add your calculation to that workflow. MAKE SURE TO SELECT “do every time”. Or you will spend 40 some minutes wondering why you’re an idiot even though you’re not. Or maybe that’s just me.
broke up and daisy-chained the custom workflows with triggers. So, instead of Workflow A doing actions 1, 2 and 3 (which are dependent on the prior action), I set up Workflow A, doing action 1, then triggering Workflow B, doing action 2, then triggering Workflow C, doing action 3.
Even though the documentation says the “pause” action won’t work, I tried it yesterday, and it seemed to work (but I can’t say so for sure b/c I didn’t test it extensively). So, I added a 100ms pause at the beginning (Step 1) of every workflow (A, B & C).
NOTE: I did not add repeating workflows “only when” sum not equal to total value (2nd bite at the apple)
Results: With limited testing, so far so good. There were no calculation errors.
I will update this thread, as more testing is done. If occasional errors crop up, I will either add the repeating workflows option or further investigate @duke.severn solution of a “listener” workflow triggered when data changes, which may be the better solution after all.
Oh cool! I hadn’t thought of this. Cautioning new users against using this method too many times in your app, and using a preset style across the app because loading UI elements and their styles multiple times, say in an RG, might get heavy.
This is cool too. Do you need the pauses? Since the workflow would only trigger in order? What happens if you remove the pause at the beginning, does it still work?
As I understand it, when adding any action (pause for example), it add a process of approx. 200 ms (Bubble capacity of 1 unit). If you add 40 units, then the 200ms become 20ms (approx), so the result will be different (as pause will have no effect anymore). I hope we will have a clear statement eventually (it’s changing in time as the server is used by many). BTW my statement of 200 ms is maybe 300 ms now.
This is what I meant (“Please note”). So I think the workflow will queue on-screen actions (show/hide, navigate, animate, display data and a handful of others) and immediately process any backend actions. This would seem consistent with what @JohnMark is saying: adding a workflow action (any action) would delay the following workflows a bit. But I assume scheduling the workflows themselves would force a pause in seconds, and not be based on performance. Makes sense to me that it would work - but I would be grinding my teeth at night thinking that I’m forcing my users to wait longer than what their hardware would normally allow… I haven’t read any more on what the “inline” pause vs scheduled workflow pause does so this is by testing and feeling.