How to execute rest of workflow if something failed underway?

Hi there, a quick & easy question:

For workflows that take some time to execute, I tend to start them by showing a rotating spinner, and hide it again after the workflow terminated. This helps users understand that they have to wait. Some workflows may fail underway, for instance when someone attempts to modify an e-mail address that doesn’t exist. This triggers a bubble warning popup, and cuts off the rest of the workflow. So the spinner won’t be hidden and keeps turning forever, this is bad.

  • Is there a way to tell a workflow to execute some of its remaining independent parts after a preceding part failed ?

  • Is there a good approach of how to best treat failed procedures within a workflow?

Thanks for any hints, have a nice week-end,

O.

I’d be interested in any recommendations anyone has here. My approach has been in a scenario where an API workflow is progressing. In this case the way I’ve applied the rationale is to make a change to that user when I send the details to the API workflow endpoint which in turn initiates a visible indicator to that given user that something is happening. Just for completeness my workflow can take between 30 and 40 seconds and this is acceptable. Now I’ve always struggled with the gnarly issue that if for whatever reason the workflow fails the visible indicator remains. So all I’ve done is scheduled an API workflow to kill that after a period of time… 60 seconds in my case. If the workflow does complete then I simply cancel that scheduled workflow to kill the visible process.

I am sure there is a much more elegant way of doing this

I don’t think you pick and choose which actions would be performed after an error, but you know about the unhandled error event, right? This should be able to at least hide your spinner (when it isn’t an api workflow.) Maybe you could trigger some of your other actions?

Also, can you do some validation before the workflow executes to check for these potential error triggers? For example, check the e-mail address on the workflow event, and let the user know of the error before anything actual starts.

3 Likes

Hi Ken,

thanks for the suggestions !

One of these situations occurs when privacy rules hide database information, but some generic bubble functions within a workflow know something about said data anyways.

Example: a privacy rule blocks users that aren’t logged in from accessing the User database, particularly the login email field. This is very good. But a bubble pwd reset function will have to check the list of login-emails anyways. If the user remembers his login wrong and wants to change his pwd, this will trigger a bubble error popup that seems impossible to detect before it happens.

There may be more cases like this linked to the data cloaking nature of privacy rules.

All the best, till soon, O.

Hi Bubbleboy,

thank you so much, your case is very cool. You are using the API workflow like an ambulance team coming in and cleaning up the scene after the actor has fallen from the stage :stuck_out_tongue_closed_eyes:. This should almost be included as a standard in bubble’s workflow elements. In most software there are error flags popping up when something didn’t go according to plan. We are missing that in the bubble workflows, or maybe I still don’t understand bubble well enough.

Superb contribution, thank you again ! Regards, O.