Order of actions inside an event


I built my app under the assumption that the actions of an event make effect one after another (following the order) and not simultaneously.
When testing my app, this logic seemed to be indeed applied, since I never noticed before a behaviour that could contradict it, until lately with this example:

Without understanding why, I noticed that in this case, step 6 makes effect before steps 4 & 5.
That’s a problem because steps 4 & 5 depend on the thing deleted in step 6.
In the same way, it would cause an issue every time a previous step refers to a thing, before its changes ordered in the following steps.

Thus, I’m wondering if it’s a bug or if it means that I have to review the workflow of all my pages.

In this topic, @emmanuel explained that workflows run at the same time, but what about the actions inside an event?

Unfortunately, the actions don’t necessarily happen in order. They generally seem to happen in order, but they’re not guaranteed to work that way and sometimes almost always don’t run in order.


I remember back to when that became clear to me…changed how I build things for sure. Here’s a couple things I normally use now:

–In the when condition of an action, check something based on a previous action that will always be true. For example, I often use, Only when Result of Step x’s unique id <> -1, which is always true. Similarly, you can use the Terminate this workflow action with the same condition.

–Layer your steps. Fire off a group of actions that work nicely together, then call another custom event with actions you need to be performed later.


Thanks @sridharan.s for your reply! Sad to hear that, it would be so much easier to have successive actions.

@mebeingken thanks for your adivce! If you have time, could you please suggest how to apply your tips in the specific case described above in the first post, just to have a concrete example and understand better how to adopt best practices?
So, you mean that custom events are triggered after regular actions?

As for the action “Terminate this workflow”, it seems way less useful, without the guarantee to respect the order.

A little difficult not seeing your app, but I would try this for starters:

Create a new custom event, and move step 6 into that custom event since you want that to run after 4 & 5.

After step 5 (now the end) make a new action, Trigger a custom event, and point to the event you just made.

Oh, and I forgot to mention using the Add a pause before next action, action. If the above works, great. If not, try inserting a pause before step 6 – my guess is something like 250ms will be enough. The docs say the pause is only for actions happening on the screen, but it has worked for me when I thought it might not!

Ok, thanks, but if we follow this rule, we should also be careful with step 1, right?
Indeed, if there’s no guarantee that step 1 happens first, then it could affect all the other actions, since they all depend on the status ok/error of the custom state defined in step 1.

Also, about your tip in the “when condition” area, do you have a usecase in mind for example?

I think it is more about being careful with dependencies, not specifically step 1. If an action is dependent on a previous action, one has to consider the impact of those happening in an order not anticipated. Perhaps in your example it all stems from step 1, so perhaps you are correct here, but it really is about dependency. If everything depends on that state, you might want to set the state, then call another custom event. The truth is, some times it is fine, and sometimes it bites you. Some actions take longer than others, etc. I even see differences in debug mode vs. run…so I tend to plan for the worst. By the way, you can also define a custom event with a type of thing parameter, which allows you to pass it a value. In your case, you could pass the value into the custom event from step 1, which in and of itself, will create a dependency you can count on.

One example I have is from a basic data add or modify routine. I often have routines that modify a thing, or create it if it doesn’t yet exist. Picture an entry with a few dozen fields. Rather than inserting all those fields on both the create and the modify action, I put them all on the modify action only. I create a new thing if needed, then turn right around and modify it. It makes maintenance down the road easier as well. But this means that the modify must do a search to find the thing, because it may have been created some time ago, OR during this routine. So I will place a when condition on the mod, that makes sure the create has completed.

Thank you @mebeingken for taking time to answer!


Could someone from Bubble team please add a clarification on the execution system of actions: when I test my app, if the actions seem to be executed following the order desired (that is to say, if the test meets my expectations), does it guarantee me that they will always be running the same way, or can the execution order change randomly everytime the page is loaded?

I believe there’s no guarantee in order of execution
Especially in api workflows on lists

You are a star! This simple trick saved my life. Thanks!

1 Like

Hello people. I’m starting with Bubble and this is Incredibly Disappointing. because the system even puts the actions in numerical order. I don’t see how to have a programming logic without respecting the order in which actions are carried out. I am abandoning the Product. I will have to look for another platform … Regrettable.


The debugger doesn’t match up with the workflow. Took me a while to figure that out