Does a pause and a "Result of" condition not force synchronous execution of Workflow steps?

I’m going nuts here trying to force some things to happen in a specific order. I am calling backend workflows and using “Result of Step X” in the conditions, and additionally I’m using pauses to try to force things to happen in the order I need:

These steps must happen in this order:

  • Step 2: Calculate Delivery Fees
  • Step 4: Totalize Delivery Fees
  • Step 5: Show the “Pay Now” button

However, with the setup now, the order that it’s actually executing in is:

  • Step 4: Totalize Delivery Fees
  • Step 5: Show the “Pay Now” button
  • Step 2: Calculate Delivery Fees

The reason I know this is that the “total” amount is always shown from the previous delivery fees. That means the totalization is happening before the recalculation of delivery fees.

This goes totally against what I had thought was true based on these comments, which are direct quotes of the documentation.

Am I missing something here?

1 Like

Just off hand - Adding a pause only usually effects front end, not back end. As far as the Result of… it won’t work for backend API’s since it’s not actually waiting for your Step 2 API workflow to finish.

In other words, your Step 2 API runs… and instantly returns a “result” even though the Backend Workflow may not have finished… So Step 4 immediately runs since Step 2 “has already run”. I believe the “Result of” an API call is just some reference to the Backend API ID. You can test this by scheduling an API into the future… then going to “Scheduler” in your Logs and checking to see if the “Result of” equals the ID of the Scheduler API.

I feel your pain here. I’m a 5 year veteran of Bubble and still routinely spend hours debugging stuff like this.

Will be watching this – I hope I am wrong on my assessment above!!!

Edit: God if only we had a checkbox in the workflow for “Run in sync” (actually run this workflow in steps and wait for the previous step to finish), all of our problems would be solved!!


Is this the same app as the other thread we were talking in? Do you mind showing the workflows for your delivery fee calc and totalize delivery fees? And also it’s true the pause before next action is only for the end user for delaying animations, etc. Workflows still run full speed.

Is it possible to calc the delivery fee, and also calc the totalize fee at the same time, just the totalize fee contains the same math as the delivery fee?

As mentioned already, the ‘Add pause before next action’ only applies to front-end action like showing and hiding elements etc. And even if it did apply to server actions like database changes, you wouldn’t want to rely on a pause, as there’s still no way to know whether the previous action has completed or not…

What do your backend workflows do? I’m guessing they’re making some changes to data in the database?..

In which case you can use conditional workflows, or custom events triggered when data changes, to trigger the next workflow only when the data has been updated by the backend workflow… thus ensuring your workflows run in the correct sequence…

Or you could move them all to the front end, then the Result of previous step should force them to run in order… (or use custom events, which will also run in order)


Further, those backend workflows do not return what the OP thinks they will return to the workflow. They are thinking that the scheduled workflow will return the results of the computation to the client-side workflow. Of course, they do not. What they return is the ID of the scheduled workflow. TLDR: OP is doin’ it rong.


I wish the Return data to API would return data back to the client that scheduled it…

1 Like

It does when you call that workflow vial the api connector :wink:


True I was thinking that while typing it. I was going to test it and see if it was any slower than calling it internally (probably).

Just gotta figure out how to authenticate the call

Issue yourself a key and use Authorization Bearer: key. (It is a little buried in the docs!)

1 Like

Thank you everyone! I learned a number of things!!! The main thing is that when the documentation talks about workflows, that only applies to frontend workflows not backend!

Same goes for pauses, but now I’m starting to doubt if a pause actually causes it to wait for previous steps to complete or if it just pauses for the specified amount of time.

Lol, yes! But in my defense, the official documentation is really unclear on this point and I believe many others reading the documentation would also fall into the same mistake. It should really clarify that the “Result of…” does not wait for a workflow to end if it’s a backend workflow.

I was able to move my workflows to the frontend. Calling a custom frontend workflow, and using the “Result of Step…” it does indeed wait for the workflow to complete.

However, there are cases where it really shouldn’t be a frontend workflow but a backend workflow.
Still not sure how to solve those types of cases. Let me see if I can unpack all this, as it sounds promising:

Conditional workflows

  • I think this means that the event triggers multiple workflows which all have conditions such that only one fires. I can see how this works if its an either/or (e.g. does the thing exist?) but I don’t see how this would work when I want to do A and then also do B. Because both conditions would be evaluated at once, so if A runs and B does not, there’s no way to make B run later after A finishes.

custom events triggered when data changes

  • I assume you mean a backend event (can this be done on the frontend??)
  • I can see how this would work. Drawbacks are :
    • If calculations are complex and making multiple calculations/writing the change multiple times in multiple steps, then the backend workflow could fire multiple times and potentially you could get a race condition where the first one to fire takes longer than a later one, and therefore ends up overwriting the correct final result with an incorrect one.
    • There isn’t a way to notify the frontend when the backend workflow finishes, which means this doesn’t work for something that has a frontend component to it, e.g. show the total only once it’s finished being calculated. (Although I suppose you could create another field like is_calculating and have the backend workflow set it to no when complete and the frontend could key off of that, but it’s a lot of extra steps!)

I have been looking for a comprehensive answer on this for months. Just yesterday I read through dozens of posts from poor souls trying to understand various problems related to running things synchronously.

What’s so sad is that the majority of these questions never got a single answer, and were closed. :frowning:

I think the community would really benefit from Bubble pros taking the time to comprehensively organize all of the various strategies that are possible for ensuring that workflows run synchronously, with detailed explanations of the caveats of each situation and when they will and won’t work.

I’ve discovered a few new tricks for my toolbelt in this thread, but I still don’t feel confident that I understand how to ensure synchronicity in every situation I may need it in the future.


But it does. It waits for the workflow step to initiate itself and generate a reference number.

The previous iterations of workflows (all serial) were not ideal either. They were VERY slow.

I think this is around the wrong way, although I understand the sentiment.

We should WANT workflows to behave in an async fashion as much as possible.


Just to be clear on what you’re saying:

Are you saying that if you use “Result of Step…” on a backend workflow, that it will wait until that backend workflow ends before continuing?

Because that seems to go directly against what 4 others just said above, as well as my experience.

I think possibly you mean it waits for the backend workflow to start.

Not quite…

By conditional workflow, I mean a ‘Do when condition is true’ workflow event… the condition can be anything you like, such as a specific piece of data has been modified…

To do that you can set the current data value in a custom state, then compare it to the value in the database using a ‘Do when condition is true’ workflow event - the condition being when the database value is NOT the custom state value, and then run a workflow accordingly…

So, if your initial workflow has an action to trigger a backend workflow which modifies some data, you’d want to have another workflow that runs only when that data has been modified (i.e. if the DB value does not match the custom state value on the page). That way the workflow will only trigger once the data has been changed. You can ‘chain’ together as many workflows as you like, this way, thus ensuring that actions only happen when the data has been updated accordingly in the database.

custom events triggered when data changes
I assume you mean a backend event (can this be done on the frontend??)

No, I’m talking about frontend Custom Events…

If you trigger a Custom Event from within a workflow, the workflow will pause, run the custom event, and then only when all actions in the custom event have completed, the original workflow will resume. You can have a series of Custom Events triggered from within a workflow, so they will run in the order they are in, then next one only starting when the previous one has completed.

You can also use the ‘Trigger a custom event when data changes’ action, specifically to trigger a custom event when some data in the database changes, but there are some limitations with that approach…


I get what you’re saying. When I first started with Bubble I kept running into pain points where I wanted to get Bubble to do things a certain way, but then discovered that there’s a much simpler way to do it in Bubble that’s easier and better.

And I agree that people should first understand how to do things the “Bubble way.” But there are always going to be edge cases where it’s important for things to happen synchronously. (I am curious if you disagree on that point.)

In my experience, knowledge is power. Right now, I don’t fully understand which things will guarantee synchronicity and which won’t. Having this information will make me a much better Bubble developer. Don’t you agree?

1 Like

Genius, @adamhholmes !! Thanks for explaining that. I can see now how that works. Really useful!!

Agreed - Most of the time, this is ideal… However, I have edge cases all around my apps where I really need a certain series of workflows to run synchronously. We should have the option to do both.

I’ve been advocating for a simple checkbox. “Run workflow synchronously” or “Follow Steps in Workflow”. Each step runs as expected. It waits for the previous step before it. Step 1 → Step 2 → Step 3 → Step 4 → etc. Add a caveat that “Hey, this might work slower because it’s not asynchronous!” (which is fine, I don’t mind putting up a spinner.)

So, yes, keep async because most of the time, it’s ideal, it’s fast… however, give us the option for an easy way to make it synchronous without all of this tedious workaround. :frowning:


A checkbox would definitely be easiest for beginners. But then the whole workflow is synchronous. And many will check it when it is not the best idea.

However, if we could just get clear information on how to make things synchronous in different steps (e.g. using some of the tricks discussed in this thread) and have that clearly written out and documented somewhere, it would help anyone who runs into one of these edge cases solve the problem.

The documentation could even have a long section on why running things synchronously is “code smell” and helping think through ways to restructure things so that it’s possible to accomplish the same thing asynchronously.

I don’t think this knowledge is collected anywhere. The closest thing is what I linked to on the first post of this thread, but there’s SO much information missing!!! And I’ve combed through the forum and read dozens of posts on this same topic. There’s not clear answers anywhere.

1 Like