@sridharan.s’s observations are spot on and helpful as always here, but I kinda have another suggestion for you:
It sounds like you’re really trying to do (rather than do down-to-the-millisecond analysis of some workflow) is to force some steps in a workflow that are being executed asynchronously (which is usually desirable) to execute synchronously.
If you want to force such a condition in a workflow, you can do it by inserting a pause step. Step 1 → Pause (doesn’t matter the length, it can be whatever the minimum is) → Step 3.
Inside of Bubble, this basically creates (maybe actually literally DOES) create an “await” type of event (if you’re familiar with JavaScript stuff). Basically, the Pause step awaits completion of Step 1 and will not do its pause thing until Step 1 is actually complete. Step 3 will not begin execution until the Pause step has completed (it awaits completion of that step).
It is possible to have situations where doing this is desirable, but they’re really pretty rare. Usually, synchronous execution vs asynchronous execution of workflow steps is handled just fine.
But one way that Bubble “figures this out” (if you will) is that some later workflow step refers to “the Result of” some earlier step. Most (all???) workflow actions report a “Result” that later actions can inspect in their “Only when” field. So this is a more natural way of ensuring that some later step does not execute until the previous step is done.
(Because whether the Result of the previous step is “empty”, “not empty”, some value, some thing, etc. can only be evaluated after that step has completed.)
@mishav explains it pretty well in this comment on one of your previous posts: