I’m not sure if this has been mentioned but i I had a nearly identical flow in my delivery app - I did it with a calculation, and then a show element. I’d have to look back into that app to get the exact calculation I used.
No, I am saying that the workflow does just enough to get everything ready to pass the “result” back (which is not the same as all the possible results from all the downstream steps)
So in one sense … it sort of does wait. But doesn’t wait in the way we might want to wait.
We should also bear in mind that a workflow can call other workflows etc etc
So “done” in this case is almost impossible for Bubble to know.
There are ways around this, such as storing target iterations and current iterations on the database. But it all gets quite complex.
Again, I think beginners would tick them every time, and not really know why.
It should be an advanced setting, because for most people it is not optimal to run in serial.
But you can anyway using Custom Events. But it is messy.
I agree, I’m fact I made that same point in the next sentence.
I am not even advocating for new features. I’m just advocating for detailed and comprehensive information about how the current system works and what strategies can be used to make things fire synchronously.
I put everything that needs to be processed in the Backend Workflows a long time ago. Main reason: when someone refreshes his browser during any calculation… Second reason: No waiting on the browser side and especially lighter during Page Load.
Hey JohnMark, in my case I was actually using backend workflows as well.
Do you have any ideas on how to guarantee synchronicity in backend workflows? It sounds like you have a way.
Tips: I use the Wait plugin and I also use the Terminate action a lot (even though I don’t need it). It tells Bubble to finish first, then continue. It’s a kind of stopper. Of course, I always use the Only When action referenced the step before.
And last, I’m using a lot of colours to identify every process and recently I put my Safari browser in Dark Mode (ouffff).
Hi,
Just adding a brick to the wall here.
This hidden post answers most of your questions 
It should be on the documentation.
General rules about how workflows run:
- Frontend workflow actions run in order but the next action does not wait on the previous action to be complete before triggering.
- Backend workflows are triggered as soon as the workflow is triggered, independently from steps. For example, a ‘Schedule API Workflow’ action will be triggered as soon as the workflow is triggered even if it is placed last in the workflow action sequence.
- Custom events run in sequence, not parallel. If Workflow 1 triggers a custom event that starts Workflow 2, Workflow 2 will complete before the remaining actions in Workflow 1 run.
- Searches aren’t always immediately updated with new data. So if you create a new item, and then try to retrieve it via search, it may or may not work; you should not rely on this.
- Retrieving a thing from “result of step X” where step X is the “Create…” step should always be safe.
Workarounds to help achieve workflow consistency:
- When a workflow trigger (eg. a button) can have multiple results based on conditions, it is safer to create multiple workflows and place the conditions at the workflow level instead of creating one workflow with all possible actions and placing the conditions at the action level.
- In a workflow with two actions, if Step 2 is using a condition based on a search depending on data manipulated in Step 1, then Step 1 should be implemented into a custom event to make sure it is finished before moving on to Step 2.
- If a backend workflow should be triggered after other steps in the workflow, then it should be implemented in a custom event placed after the steps that need to come first.
- The safest way to use data from one step to another is to use the “result of step X” operators instead of searches.
- We do not offer the explicit ability for an action to wait for a workflow to be over before moving on to the next step; however, using ‘add a pause before next action’ action is usually an effective workaround.
Psst, look at the first post again. I quoted directly from that in my initial question. 