Order of Operation

darn i was just here. wish id known this 2 weeks ago

1 Like

This has been hugely helpful for me and, generally, great advice. That said, I am running into an issue that cuts against the grain of some of these assumptions, and I’m hoping you might have an explanation. I have a custom event that (essentially) runs conditionally, based on the value of a custom state. I toggle the state to “yes” (using a second custom event) before triggering this custom event and then toggle it to “no” (using a third custom event) after it has completed. Given this structure, where each step is wrapped inside a custom event, I would expect each one to run synchronously, as outlined above. That said, this is not what is happening. Instead, the workflow is getting hung up in infinite loops. It seems like everything does work as expected when using the debugger, so I know the logic is sound. It’s just that the workflow does not seem to be waiting for the custom event to complete before moving on to the next one. Can you explain this?

Yours and @aaronsheldon’s points would seem to be very important ones that deserve being highlighted in the OG post, since most folks rely on plugins. I’m currently facing this issue myself and has left me scratching my head.

Hey @ts11 - I assume that the “Loading Shapes” state is the state you’re toggling with the “Set Loading State” steps? And that one of these is setting the state to yes and the next is setting it to no (it kind of doesn’t matter which).

I don’t know anything about the What3Words plugin, but it looks like you’re referencing some exposed state “A marker has been drawn”. I can only assume that this goes high once and stays there. I think you’re expecting it to be a triggered event instead?

Anyway (if what I describe above is the situation), if “A marker has been drawn” is just a state that is always high after some point, you’re causing that “When What3Words” workflow to trigger infinitely simply by toggling “Loading State”.

Every time it goes from yes to no this workflow will trigger. So it’s essentially just triggering itself over and over and over and…

This would work properly if there were some explicit triggered event triggering this workflow (which may or may not need the additional conditions as its “only when” condition).

1 Like

Thanks so much for jumping in here, Keith, and apologies for the rather lack-luster explanation of my setup. Yes to the synopsis of the “Loading Shapes” state. However, that “marker has been drawn” event is actually raised each time a new marker is drawn on a map. I think I solved the issue by moving the condition from a state to a field on the map record and playing around with my order of operations. I think the problem was ultimately with one of my custom events, where the “draw shape” actions were placed before a custom event to toggle that “shapes loading” variable. I ended up moving the state change to a “schedule custom event” step to ensure a delay between the drawing of the shapes and the changing of the variable.

Clear as mud, I’m sure. At any rate, it works! (For now)

1 Like

But further to your other comment, @ts11, I do find that, in some cases the approach of grouping sets of actions into a Custom Event and then having a workflow composed solely of Custom Events in some sequence, does not always achieve what is desired.

Specifically, one place I ran into this is with the Floppy element (from my Floppy browser storage and stuff plugin collection), which even though its various data manipulation actions are synchronous with respect to each other (and with respect to certain native Bubble actions like Set State), it seems that it was impossible to make them synchronous with respect to actions like “Create/Make Changes to a Thing”.

Now, there are complex reasons that Floppy might behave this way (so this shouldn’t be taken as a general comment on plugins), but I introduced a feature (“Sync Triggers”) that can be used to abso-defo-lutely be sure that some Floppy action is fully complete before moving on to some action that stubbornly refuses to wait. :wink:

I talk about this stuff in a rather off-the-cuff video here:


I’ll have to take a look at this!

They’ll probably be a part 2 as well, but I was kind of in a hurry. At any rate, I don’t show every single-dingle permutation of what one might try, but in this particular case, no sensible approach works besides listening for a specific event triggered by the plugin.

(Also, wrt your workflow picture - the way Bubble auto-labels workflows makes it kinda hard to understand if something is a state or a trigger, so I don’t feel like you were being lazy there! But I was like: well, if that’s a state, I see an infinite loop here. That exact situation is another reason that I really want the Client-side Actions API to be able to return values to the workflow, because that would make it possible to have “in workflow” states that only exist within the context of the workflow and wouldn’t cause potential loops.)

1 Like

Does anyone know what is the order of operations in case of backend workflows? I mean if there are step1, step2 etc within a backend workflow then would they run in sequence or the logic mentioned by @aschofer is valid for backend workflows too?

What @aschofer mentioned and so is in the documentation is that the logic given is only applicable to “frontend workflows”, hence the confusion.

1 Like
  • 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.

Could someone please confirm this is actually correct? I only ask because on the pause action in bubble, it says that it is will only affect graphical elements and not data & variables etc… so just wanted to clarify.


Some more clarifications here.

Say, we have a backend workflow that has a few steps like this

Action 1 → Action 2 → Action 3 → Custom Event 1 → Custom Event 2 → Action 4 → Schedule API1 → Action 5 → Custom Event 3

Here, I understand that Action 1, 2, 3 can run in parallel. However, is there a guarantee that Custom event 1 will run only after action 1, 2,3 are done?
Is there a guarantee that Action 4 will run only after Custom Event 2 has run?
Is there a guarantee that Schedule API1 will happen only after Custom Event 2 is run?
Is there a guarantee that Custom Event 3 will run only after all other operations are done?

1 Like

Here based on my understanding: @mghatiya


I :pray: for a button to just tell an action wait for another list of actions to complete


What kind of operations? New data entry =>
Can’t you schedule custom event if Step x’s result is not empty or something

Big dawg replied to me by accident :skull:

No home-e I’m talking to you!

1 Like

For my case IDK it was some odd thing where you create something then also need to search and add the Totals of existing things plus the new thing (I think, probably multiple different cases).

Of course there’s workaround like custom events, wish there was like a 2D tree of workflows branching out indicating what’s waiting on what, etc. Bubble is a visual editor of course

I wish you could tell it “IDC about the extra 20ms time” and I know I’m not the first to want it :laughing:

But people are on some serious Copium if they think custom events waiting on each other not being able to return data to each other is an intuitive way for us to make sure actions wait on each others’ completion


I was under the impression like if you’re creating a new data entry, you’d use the result of step x so that the next action won’t execute until there’s an answer. But yea, how would you handle other non-data thingy’s? Idk, me dumby.

1 Like

When Bubble updates its workflow editor GUI, they should design it in a way to visually indicate the order of operations. Little dotted arrows or something. Total redesign of the gui.


Imagine nodes you can move around in free space (on a fine grid so it looks nice) and you just draw lines from outputs to inputs and check “wait for steps X, Y, Z” and conditions being their own block where the path splits depending on yes or no :slightly_smiling_face: