Force Workflow Steps to Happen in Order

[chris.williamson1996]

When I have this issue on long workflows I break it up into states/workflows

Try using a custom state on your parent group called like “api success” it is a Boolean Default no

Break the original workflow down and when action is complete set state to yes

Then have a workflow for “when a conditional is true” -> when parent group “api success” is yes
-> (2nd part of original workflow)

Make sure you empty the state and have the conditional workflow set to every time rather than one time.

You can do this multiple times if needed.

[kefa.kabanga]

I thought that this was brilliant and destined to work and celebrated.

Unfortunately, it did not. The next trigger was called before the first was done. I haven’t yet figured out why.

[boston85719]

You should do what @chris.williamson1996 mentioned…it is the same as below but with more direction provided

@boston85719

Another thing that you may do is create a conditional workflow that will trigger the booking with the conditional being met when the earlier steps are complete.

[dehacked79]

Set step 2 to use result of step 1 in one of it’s value fields. Seems to be a pretty reliable way of enforcing sequential execution.

[chris.williamson1996]

Customs don’t work because the custom triggers and instantly starts the flow regardless of others being done with a full response from external sources.

Using states like I mentioned above works the same way API response events work by not triggering until a api response isn’t empty.

[kefa.kabanga]

Thanks for this @chris.williamson1996,

Really interesting suggestion and I’ve reworked the workflows to make it function as you’ve laid out in addition to incorporating @adamhholmes suggestion . However, after much testing, it still doesn’t reliably work to my utter confusion. It seems to work at normal speed, but not at step-by-step speed, which really confuses me and makes debugging of other issues rather impossible.

TL;DR: Slow Mode and Step-By-Step mode seem to have a bug at the Bubble level that normal mode does not that makes step-by-step or slow debugging nearly impossible.

The high level workflow is now broken into three major (error prone) sub-stages:

In the first, I have triggered the pre booking checks, and added before & after states, as per your guidance.

Once the final “Ready for Booking” Error state is changed to a yes, and only when it is yes, should the next stage, the booking, begin:

Despite two levels of checking whether the condition has been met, the booking somehow still happens. I’ve isolated it to the booking and not the error states, because removal of the booking stage from the workflows doesn’t result in a booking.

On the debug step by step mode, it claims to work exactly as you said it would: the booking workflow does not get triggered. However, the reality is that it does get triggered even though it shows as not triggering in debug step by step mode. Weirdly, in the normal mode, it functions (so far) as intended.

I make a booking:

The top level workflow is triggered:

And before it gets to the trigger booking, it’s already made the booking:

This seems to be an issue with the step-by-step mode of debug. With the normal mode, the issue seems resolved by following what you @chris.williamson1996 and @adamhholmes said in combination. The bubble loading bar still chugs on even in debug step-by-step mode.

To test this, I made shapes appear within each workflow and disappear within the next workflow, so that if the workflow was entered, I’d know, and I’d see if the same actions responded differently in normal mode vs. step-by-step mode.

Different shapes appeared depending on the mode chosen. In normal mode, the shape that was supposed to appear in the first trigger and disappear in the second trigger (shape jemima) never appeared at all. The shape meant to appear in the second trigger and disappear in the third trigger did just that (shape williamson). The shape meant to appear in the third trigger and disappear at the end of the workflow (shape adam) never appeared at all.

Slow mode and step-by-step mode result in a different sequence (and thus different boxes). In Slow mode, the first box in the first trigger (shape jemima) appears. Slow mode / step-by-step mode invariably results in an error being created, and thus the condition for triggering the other steps not being initiated, the other shapes for trigger 2 (shape williamson) and trigger 3 (shape adams) are never called, and shape jemima is never hidden.

TL;DR: Slow Mode and Step-By-Step mode seem to have a bug at the Bubble level that normal mode does not that makes step-by-step or slow debugging nearly impossible.

[chris.williamson1996]

Try running this without custom events.

Rather click the add a new workflow for under your workflow tab

“when condition used true”

This will trigger the event upon state being true run the workflow then reset state. Rather than you triggering a custom in the prior flow.

What this does is say hey do action 1 from the original workflow add a wait 1-5s then set state of the parent group to true.

Upon the state being it will then and only then trigger the workflow.

If you do with customs it does a check for yes no instantly rather than waiting for a finish on the first flow.

Hope that makes sense.

[kefa.kabanga]

Hi @chris.williamson1996,

I followed what you said. It works, but step-by-step mode now crashes bubble.

[jesse.r.hunter]

Yeah we run into this all the time. Huge race condition. This is because workflows do NOT execute sequentially across all actions as one would think. It actually executes them based on action type in three different sequential buckets, in parallel. The actions are split up as:

-API calls
-DB actions (make changes/create new thing/etc)
-Everything else / State changes / Visual actions (hiding/animating/display data/etc)

The engine appears to pre-scan your workflow, schedule API calls it can first, make DB changes second, and then call anything else last. We solve this via two primary methods:

calling an action with conditional “Result of stepX is not empty” on a DB action will ensure the DB is evaluated prior to the conditional action ensuing

SCHEDULING (not triggering) a custom event will ensure it happens apart from the race condition (hence place your latter conditional action in a custom workflow then schedule it with a 1 second delay) EDIT: also add a terminate workflow conditional on the start of your scheduled workflow to abort if your undesired fail-state occurs regarding your booking)

[vitorbgaspar]

Thnaks @jesse.r.hunter ! In my case I’m trying to send an email to admin after the user registers an offer but the …conditional “Result of stepX is not empty”… makes the send email step to fail. Any workaround on this besides schuduling custom events?

[jesse.r.hunter]

{Result of StepX is not empty} is only actually empty for:
-Inserts that fail to actually isnert due to a constraint violation or something similar
-Updates that don’t actually update anything (the search returns no rows on what to update)
-All deletes (which I hate, returning rows affected would’ve been sweet)

If you are creating/registering a DB object, that’s an insert, and shouldn’t actually return empty. Mind sharingg your workflow via screenshot? What could also be a solution is on the email step, set the Do When conditional to be Result of StepX:count > 0

[samnichols]

This is such a frustrating problem! I’m dealing with the same issue. It would be REALLY nice if Bubble just had a checkbox for the entire workflow to “Force actions to execute in order” so we could just check or uncheck the box when needed.

[apicedigital]

Same painful issue here

[jonah.deleseleuc]

If the actions are server side, they happen one after another. If the actions are clientside, they happen all at the same time. This is true not only for Bubble but for pretty much everything in web dev

[keith]

That’s not exactly true as some actions are synchronous (set state for example) and many can be made to behave synchronously (e.g., create, make changes) when they depend on the outputs of previous workflow steps. Also Element Actions in plugin elements can be made to behave synchronously (as they do in Floppy).

So, one cannot accurately describe workflow behavior this simply.

[jonah.deleseleuc]

True dat. I mistakenly assumed it works the same as plugin ssa’s and plugin client side ssa’s.

[keith]

Yeah, client side Action plugins (not to be confused with Element Actions or with server-side actions) don’t really have any way to be synchronous (also, the API there is pretty deficient for doing anything “data-ey” as they can’t return values to the workflow).

So they’re kind of only useful for things we might do to manipulate the DOM. Like the other day I saw someone had done a little “confetti shower” plugin and that was the first example I’ve seen in a while of a good use for the client-side Action API

[dodo]

@chris.williamson1996

When I have this issue on long workflows I break it up into states/workflows

Try using a custom state on your parent group called like “api success” it is a Boolean Default no

Break the original workflow down and when action is complete set state to yes

Then have a workflow for “when a conditional is true” → when parent group “api success” is yes
→ (2nd part of original workflow)

Make sure you empty the state and have the conditional workflow set to every time rather than one time.

You can do this multiple times if needed.

@chris.williamson1996

This is how I am dealing with it. It worked, but I still have a doubt.

In the example below, step 5 is setting the Refresh Chart custom state to “yes”:

WORKFLOW PART 1

Consequently, the “when a conditional is true” is triggered and step 5 of workflow part 2 resets the Refresh Chart custom state back to “no”, so that the “when a conditional is true” can be triggered again if needed.

WORFLOW PART 2

My doubt is the following: how do I make sure that step 5 in workflow part 1 is not setting the Refresh Chart custom state to “yes” before the previous steps 1, 2, 3 and 4 have completed?

You wrote: “Break the original workflow down and when action is complete set state to yes”

How do I tell to step 5 of workflow part 1 that previous actions were completed?

Thanks!
Dodo

[mdong185]

Wow thank you for this thread. Had a “Make change to thing” that was X = X+input and following conditional based on X. Was trying to use step-by-step mode to understand what was happening but the bug remains.

Ended up using result of previous step to enforce the sequence. Thanks for all the help!

[rico.trevisan]

FYI: Tip: Order of Operation - #2 by aschofer