I have a question on work flow and the order of operations. I have a workflow issue. I went the work flow steps to occur in order. Once the first step is complete, do the second step.
Currently, I have a workflow step and then after that workflow step, step 2 I navigate to the next page and send the data from step 1. But step 1 doesn’t finish in time and I navigate to the next page and the information is not displayed properly.
please help. thanks.
Hey there, thanks for posting! If you’re interested in Order of Operations, you might check out this section of our Custom States tutorial: How to Use Custom States | Bubble Tutorial - YouTube
Then, here is some information about Bubble workflow logic:
For efficiency purposes, workflows run in parallel across the server and the front end. Despite the names “Step 1”, “Step 2”, it is important to note that a given step does not necessarily wait for the previous one to complete before triggering the next one. The following is some information about Bubble workflow logic and general recommendations. Please also note that steps and actions are used interchangeably, but steps may be used in these examples when the order is important to note.
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:
Wow. 
sheer gold.
Does this information live anywhere else? Should this be in the manual, too?
While I much appreciate the sharing of this information by @aschofer, some feedback for the entire bubble team. If I would have known these things before I would have done so many workflows differently and would not be surprised why some of them do not work sometimes (and this would have probably resulted in less bug reports)!
Hope this kind of stuff could be added to more videos/manuals!
Definitely falls under the general bit of advice: “Don’t rely on coincidences when programming asynchronously”
Literally the best post ever.
I thing havinging a tick box for a workflow to execute sequentially would be loved by many many people.
Amazing post, thank you 
. That clarifies a lot.
Glad to hear this has been so helpful for you! This information has also been added to our manual here.
thank you Jess!
Forgot the manual, this is critical knowledge that should be in the IDE.
Wow! thanks Aschofer and bubble community !!! Y’all are the best.
Wow! thanks. This explains so much 
Hello @aschofer ,
This is some serious post and I think you guys should post an announcement or something that warns us and I hope this is not live since it´s a breaking change and it might break the logic of our applications.
As far as I can tell from our perspective, an can have thousands of workflows. So now we have to check all the workflows to see if this feature breaks it?
Is this published already? How can we tell if it affects to us and how can we take a look at the workflows affected? Do you provide any tool to check this?
I actually don´t see this as a new feature or something good but something really bad in terms of development.
So we´ve spent hours on trying to accommodate the workflows to conditions in actions and now you want us to revert that? What´t the purpose of the step 1, step 2, … then?
We´ve backend workflows based on those action conditions so how do we need to approach now? Instead of actions, create custom events for each step?
Please take a look at this example, we´re triggering an API workflow and this API workflow has action conditions. What should we do if we want those to run step by step?
Really? That´s super dangerous for the already developed workflows. Have you already deployed this?
We already relied on this. How do we go to everything and check and what if you cannot do a resultf of step …?
Please, tell me this is not already deployed because I´m super scared about this. Having to go to all the workflows and put a pause on it for each action? Really?
Please @aschofer @bubbe clarify this as much as you can because this is serious breaking changes.
What the master´s think about this @NigelG @vini_brito @Jici @johnny @keith @ZeroqodeTeam @AirDev ?
Thanks a lot for your time.
@ryanck, I can definitely understand your frustration, but @aschofer wasn’t describing new functionality or breaking changes… it was a description of how Bubble’s workflow logic currently works, and I don’t mind admitting that after 3 years of using Bubble, I was quite surprised by some of it (shame on me, probably, but it is what it is). The one that caught me the most off guard is that backend workflows are triggered as soon as the workflow is triggered, and the timing of that information coming to light for me was uncanny because I had been investigating an issue for days that was being caused by that very thing.
I think you are right, though, that if some/all of the information in that post is new to you, you almost have no choice but to go through your workflows and make sure they are working properly based on the described logic. That being said, if you aren’t experiencing issues in your app, then the workflows are likely doing what you expect them to do. I think the scary part is that they might not always do what you expect them to do if you haven’t built them with the described logic in mind.
Anyway, maybe some of the folks you tagged will share their perspective on things, but hopefully this response is at least somewhat helpful to you.
Best…
Mike
You´re right @mikeloc and I totally get your point.
I feel like this breaking change should have been said in some announcement or let us know about it prior to deploying this.
Hopefully more people will add their insights here to know if anyone is having issues like you said, what they think, …
Thanks a lot for taking the time to review my post Mike 
If a backed WF is using a Result from step X condition, will it be triggered after that step?
I’m seeing some weird behaviour with this, which was resolved delaying the execution of these backend wfs for a few seconds. So not sure whether these backend wfs actually wait until they have the result from those steps.
I’m in the same boat. Been Bubbling for years and I found a few of the items enlightening…
I really do wish there was a way to ACTUALLY run “Step 1”, “Step 2”, Step 3". It’s been a consistent issue and a challenge for me as a veteran Bubbler to ensure that my workflows are actually running as I intend them to. Frankly it’s a tiring challenge, even after all of the years of experience.
The custom event bits are incredibly enlightening to me… Wow. I will be playing with this immediately. But does bring up the question of why do I need to separate this… Dang, if there was just a checkbox on a workflow for “run synchronous”, it would eliminate all that extra hassle.
tl:dr - it was always broken. Got fixed a bit over time. Nothing sudden. But still could break in rare situations. But that is complex systems for you.
We need to start at the beginning …
Backend workflows have always been broken. Or rather “inconsistent”. There was an item on the roadmap “Workflow consistency” for a long time for just this reason. I have bugs that predate the bug reporting system on this 
A change was made to serialise them a lot more, can’t remember when but it was before “releases”.
In the meantime changes have been made to move back to being parallel without making the situation worse. There was the “Batching steps that update the same thing” recently.
The point is, and this has been mentioned above, this is art not science. Workflow steps could run in serial, but that would be the wrong thing to do 99% of the time.
OK, I need to check my privilege here, I grew up (in Bubble terms) with things like back end workflows.
So maybe I just naturally do things “the right way”? But I don’t think that is the only reason that I don’t find that many (or indeed any) consistency issues with Bubble workflows.
One project I work on can have multi-step, multi thread, backend APIs. If something that we created 5 minutes ago fails to get into the database (so I can’t then search for it) then my problems are a lot lot bigger than just that insert.
Context - in the last months we have created over 300,000 rows of data from a complex set of API calls and backend recursive workflows.
No of problems due to Bubble Order of Operation = 0
No of problems due to me = 
This conversation is reminiscent of much much older conversations along the lines of “don’t do operations on global values”. Bubble’s advice to use “previous result” and “triggers” enforce an order of operations is very much along the lines of trying to encourage developers to build synchronous operations on local values only.
In many ways it is a good thing that the Bubble engineers require the no-code developers to explicitly plan around asynchronous processes. This is largely due to the difficulties of distributed compute and storage, as summarized in ideas like the CAP theorem.
Think of it this way: The operations in a Bubble app are more like a postal service than an assembly line. Eventually someone will get back to you, but you have to wait for them to do so.
