Yesterday’s post about file locks was a starting point for more. Imagine someone is keeping a file open while your flow is trying to update the same document. What should you do when your flows may hit some failures? In quite a lot of use cases you might want to retry as your flow will otherwise fail. In this post I will go through the retry pattern.
The Retry Process
Often you might only want to retry one step, with this pattern however you could also retry on multiple steps. In the flow below the Process contains the steps that you may want to retry. In the example below I’ve only created a scope box. This scope box will contains the process steps.
The Process box is followed by retry scope that will only run when your Process fails. An example of a typical process would be an update to a SharePoint document. As we saw in yesterday’s locks post these kind of updates are likely to fail when people open documents.
In the retrying scope I’m setting a variable to true, so that I can check if we are retrying or not.
At the start of the retry process you might also want to alert people to do something. for example closing that document that is locked.
Now we can loop until we stop the retry retrying.
Within the retry loop we will start with a delay of 5 minutes. This could be set to anything but in my case there isn’t a need to retry more often. After the 5 minute wait the failing steps needs to be repeated.
The retry process is completed by setting the retry variable to either true or false. Not that it is important to set the run after settings correctly as shown above.
Now there is just one thing left to do.
After the retry part of the process there are likely more steps to run. As not every run may result in a retry, hence we need to make sure that the skipped flag is set on the next steps.