[New Feature] New Action: Terminate this workflow

If you have a long workflow that you might want to stop midway through, instead of adding the same condition to every single action past the stopping point, you can now add a “Terminate this workflow” action. The action will stop execution of subsequent workflow steps. It’s available under the “Navigation” section of the actions menu. More details here: https://bubble.io/reference#Actions.TerminateWorkflow

33 Likes

Very Very appreciated feature. Thanks.

2 Likes

I like this a lot :+1:

2 Likes

sweet baby jeebus

2 Likes

Been waiting for this! Thanks a lot team Bubble! :heart_eyes::+1:

2 Likes

Thank you!

1 Like

Great Thanks! I’ve been waiting for that.

1 Like

Couldn’t have asked for better timing! :+1: This will help me trim some extra weight on a handful of huge workflows taking up app/server resources. :chart_with_downwards_trend: :boom:

1 Like

Thank you. This is very helpful!

1 Like

Great!
Thank you.

1 Like

Thanks!

1 Like

Excellent, this is very useful. Thanks

1 Like

Cheers!

Now all you need is a IF WORK FLOW and an ELSE WORK FLOW and life will be good.

2 Likes

Maybe the “terminate this workflow” action should prevent the “navigation must be last action” error?
image

I inserted the new redirect action and the terminate workflow action at the front of an existing workflow because I don’t want to delete it, just override it. The error hasn’t prevented me from pushing dev to live, but it would be nice to get rid of it since there isn’t actually an error.

3 Likes

This looks great! Thanks for looking out and implementing this.

What does this actually do? Unless I’m missing something, the “terminate this workflow” would never get triggered, right?

I’m not sure how Bubble handles it. There’s a lot of stuff that has poor visibility.

Even with that workflow the page still loads for a split second and then redirects. So it’s not like it’s navigating right away.

Hi Josh, this is awesome, but I’m seeing that it introduces a delay, where having conditions directly on actions does not.

For example, I have made this page: https://bubble.io/page?type=page&name=terminateworkflowlag&id=forumdemo987&tab=tabs-1

In the group on the left, pressing the button creates a thing. If the checkbox is checked, it creates a thing, and then also sets that Thing’s YesNo to Yes. The condition is set directly on the action.

The group on the right does the exact same thing, but the “if checkbox is checked” condition is done using the Terminate workflow action. However, in this group, if the checkbox is checked, after pressing the button there is a delay and the progress bar appears at the top of the screen (fairly briefly, but it’s there).
Here’s a video of it happening: https://www.useloom.com/share/e3ebb71f200e4f5480d9f5b7ca54f55f

Any chance this could be avoided?

I have some problems with the delay as well. I set my progress bar to transparent but User still experiences the delay.

Thanks for reporting this. Not sure there’s an easy fix here… the reason this happens has to do with the way we run actions in the web browser and the web server. Basically, for simple data manipulations like creating or modifying a thing, Bubble actually fakes the modification in the web-browser (while making the actual change on the server) to make it feel instantaneous to the user. Then, the actual server result is reported to the browser as a real-time update. However, we can’t do this with certain actions, because they depend on information that only the server has (for instance, signing up or logging in), so when we hit one of those actions, we pause the browser-side workflow and wait for the server-side workflow to finish running.

Unfortunately, terminate this workflow is one of the actions we need to pause on, because if there’s a discrepancy between browser + server (which can happen if another user simultaneously modifies a piece of data used in the condition), we can’t just fix it after-the-fact with a real-time update, since the whole workflow is now out of sync.

Bubble’s smart enough not to wait for the server if the workflow wasn’t going to run on the server anyway (ie, it just does things in the browser, it doesn’t create or modify data), but if the workflow does need to run on the server, adding the terminate workflow action forces it to sync, which is why you see the delay.

So, unfortunately I think for now that’s just going to be one of the limitations of this feature. Note that this only affects cases where we a) have to run the workflow on the server, and b) were previously able to fake the entire workflow in the browser without syncing to the server.