Reading time: 3 - 5 minutes
19 July 2022
 |

Using Flow to Manage Process Control

Years ago, I had to implement a process for a holiday company that waited until a few days before the start of the holiday and then sent the customer an email. That’s fairly straightforward; I added a workflow which ran when the holiday’s start date was changed and waited until 3 days before this date then sent the email. However, what we soon realised was that customers change the start of their holiday and, when this happens, we had two workflows running; one that waited until the new date and the original one that waited for the old date.

On top of this, each change to the date would start a new workflow so it might not stop at two.

To solve this, parallel wait branches and an extra field were the answer. I added a new yes/no field called ‘Stop Running Workflows’. Then, in the workflow, as well as the ‘Wait until Start Date’ field, I also added a parallel ‘Wait until Stop Running Workflows equals Yes’ with a single action of Stop Workflow. Then, when a new workflow started (because the date had changed), get it to set the Stop Running Workflows field to Yes which had the effect of stopping anything that was already running. It then waited a minute before setting this back to No.

Voila. That did a great job. However, we’re now in the world of Flow and we don’t have such functionality available. So how can we do this?

I had a similar case crop up recently where, although the situation was a bit different, the logic behind it was fairly similar; I wanted to make sure that only one Flow was running at once time and, if a second one started, it needed to wait until the first one had finished. It also turns out that doing this in Flow is also fairly similar to the workflow. So, we need a new field to be able to trigger this but we don’t have a ‘wait until’ step. I thought the ‘Do..until’ would be the best bet combined with a delay. I implemented the following:

 

 As you can see, we get the User’s record (which has the locking field), check if it’s set to Yes and, if it is, wait 30 seconds then try again. Once we’re beyond this loop, set the locking field to Yes and there’s a step at the end of the Flow to set this back to No.

I saved two records within a short time from each other. Record 1 went through fine, I saw the locking field change to Yes and then back to No at the end. However, for Record 2, the Flow got stuck in the ‘Do..until’. Why wasn’t it proceeding even when I saw this field reset back to No?

Then I realised the fun of Flow. It was getting the field’s value from the ‘Get the User record’ step but no-where else was it updating it so, of course, it’s going to stay as Yes. Once I realised this, a few extra steps were needed:

  

 So it just puts this value into a variable at the start and then updates it at the end of the loop. As the ‘Do..until’ is now referring to something that changes, when I tested it with the same conditions, this did the trick.

As an extra caveat, with this logic above, I was very aware that should there be a problem with the Flow, if there were any failures in the logic, then it was never going to clear. For a case like mine, I thought I’d better add a fail safe so I added a parallel branch that waits a few minutes then sets the locking field back to No so that, if it did fail, the user wouldn’t be locked until eternity. I deliberately made the Flow fail and waited as it took 3 minutes for it to clear. Whilst that’s not an eternity, when you’re waiting for a Flow to finish, it sure felt like one.

This is one of those cases where the logic can be used for lots of different scenarios. My original example was for a holiday company and the other example in Flow was to manage process control. The main one that springs to mind is for use in Marketing; sending event reminders, confirming bookings and managing the process – you can imagine if there’s an event on, you could have a whole stream of communication leading up to it such as a ‘Thanks for booking’ email, a ‘One week to go’ email then, a few days before, a ‘Please confirm your dietary requirements’ message. The logic introduced here really can be used for anything.