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.
Does anyone know the answer?
I don’t know the answer, but could you instead reference the input’s value? …instead of referencing that same value in the database?
Yes, I could do it that way. A little more work, as the input reference would have to be changed in each of the 3 instances. Thanks.
Makes sense.
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.
Would adding a short “pause before next workflow” work to guarantee that the autobind is done before updating the data?
Also, am thinking about repeating the workflow calculation “Only when” the sum of the repeating group is not the total value in the database. A second bite at the apple, if you will.
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.
No, adding a pause affects back-end not even a little bit, in my experience. Yes, someone knows the answer. Let me know if it’s me 
Should do the things you need the things to do. Let me know if it worked or if you want me to check it out.
This also superworks. For now. You do
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.
Cheers
Paste expression in that red square. If that wasn’t clear.
The way to do this that is supported is as follows:
OK, so here is what I did:
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?
Haven’t yet tried removing the pauses and testing fully.
@duke.severn I am implementing your “listener” solution in a different section of my app to test. Will update.
I ended up using “schedule a custom event” with a 0.2 second delay in a daisy chain method (instead of just triggering the custom event). It seems reliable, but a little slow.
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.
Ok, glad you found a solution. Did you try the listener? If so, it wasn’t doing what was expected?
Interesting. So switching plans might break Robert’s method by speeding up the workflows to the point where they trigger too fast? Am I understanding correctly?
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.
