Workflow order logic somehow skipping over custom events

[davidavellan]

So it was my understanding that workflows do not entirely follow the steps as we would expect. They execute in step order, but run in parallel, so they can finish in different times. So it’s possible that step 2 could run and complete before step 1 has a chance to complete, which could be problematic if step 2 needs step 1’s output.

From what I know, this can be avoided by either referencing the output of step 1 into step 2, so step 2 has to wait for step 1 to finish. Or, if you run a custom event in step 1, step 2 has to wait until the custom event in step 1 has finished.

However, neither of these has prevented a workflow I’m working on to somehow skip over and finish the the workflow.

So my case:

1. I have a submit button that starts a workflow.
2. This submit button has a conditional to display if it can be clickable. Three different fields have to be filled out on the data type in order for this button to be clickable.
3. If a date field called “submitted on” is filled, it will be unclickable regardless of other conditions.
4. Once clicked, it runs a backend workflow to send an email, schedule a future email, and make changes to the data type, adding the date submitted on and the scheduled workflow api id.
5. This takes a second or two, and I don’t want the user to be able to double click the button and run that workflow a second time. My solution was to create a custom state called “submitted” on the button, a yes/no field, and to change the CS to yes when the button is clicked, adding a condition to make the button unclickable when the CS is yes.
6. At the end of the workflow, I would change the CS back to no, and by that point, the date field submitted on would be filled, so the button would remain unclickable.

Seemed simple enough to me. I have a WF that starts by:

1. Setting the CS to yes
2. Display an alert that action succeeded
3. Schedule an API WF
4. Set the CS back to no, using the boolean statement “Result of step 3 is empty” (which should allows result in a “no” since it should return the API WF id) to set the CS value.
   
   
   
   
   

My thinking was that the button should remain unclickable once it was clicked. But to my surprise, it went back and forth between unclickable, to clickable, then to unclickable. It seems the WF CS set to yes comes first, then somehow the WF CS set to no kicks in making it clickable again, and when the API WF finishes (setting the date field submitted on) it then goes back to unclickable.

I also reconfigured it to run two custom events in sequence.

1. Set CS to yes
2. Display alert
3. CE to schedule the API call
4. CE to set the CS value back to no
   
   
   
   
   
   
   
   

Yet it still had the same result of going back and forth.

I could just set the “submitted on date” right away, which would nip this in the bud early, but I’m trying to understand how come I couldn’t get the order to run properly here. What am I not seeing?

[klobassimon]

Hey
A simple fix here is to add a loading overlay to the page using a reusable element (pop up which is set to ‘cannot be closed by esc’).

In your workflow the first action is to ‘Show’ this popup and the last action is to HIDE this popup. This way the user has to wait till the workflow runs.

Cheers

S

[davidavellan]

The thing is that this workflow runs in about a second or so. So the loading graphic would just flash in and out, which aesthetically wouldn’t look nice as it would appear glitchy.

I have it now to set the submitted date field immediately after setting the custom state, which solves the problem, so for the user it looks like it finishes instantly, which was the desired result.

I’m still curious why the order of events I described in the top didn’t follow the expected order

[klobassimon]

The Schedule API Workflow step will trigger the backend workflow (which then takes time to run) but on the front end the next workflow step (Set State) will run immediately after the Schedule API Workflow.

So, the order of events are:
1/ Schedule API Workflow runs on the front end
2/ Set State runs on the front end
3/ Backend workflow from 1 runs

This is due to the delay between 1 and 3 so 2 skips ahead.

[davidavellan]

The error in my thinking was I thought that if the backend workflow was in a custom event, it would complete the entire event (including backend workflows) before moving to the next step. But it’s just triggering the backend workflow and moving on to the next step in the front end, and the back end finishes when it finishes.

So I understand now and what you said makes sense. Thank you for clearing that up for me.

[klobassimon]

@davidavellan Easy done! Glad I could help.