What should you do when your flows hit some failures? In this post I will go through the retry pattern.
Retry vs hopeless failures
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.
In quite a lot of use cases you might want to retry as your flow will otherwise fail and not complete.
Some failures are less suitable for retries. Imagine for example that you only want to run a flow when a specific file doesn’t exist. That kind of situation is not waiting for a person to do something. This is what I call hopeless failures.
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.
Retrying
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 with the Do Until action 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.
Next Steps
After the retry part of the process in Power Automate 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.
Discover more from SharePains by Microsoft MVP Pieter Veenstra
Subscribe to get the latest posts sent to your email.
Hi Pieter,
Please, can you tell me how to extract the “lockedByUser” email?
After Send a request to HTTP, I have tried to use the JSON parser and a compose action, but it doesn’t show any value for it.
Thank you
Claudia
HI Claudia,
Can you send me the json returned by the Send a HTTP request?
Thanks,
Pieter
Thank you Pieter, but I figured out how to do it.
Based on the result, I have created in the flow a “Send email ” action.
Please can you explain what is the role of Send an HTTP Request 2? With this action, do you want to see if the document is still locked by somebody?
Thank you
Hi Claudia,
the second Send an HTTP Request 2 is retrying the original HTTP Request, but this will only run if the previous run failed.
Could you share the steps you used to extract the locked by user’s email?
Giving this method a try tonight. I read your other, related articles on the subject, too. We’re running against document lock issues while trying to build some replacements for SP2010 workflows using Power Platform. This pattern you’ve demonstrated allows us to (hopefully) replicate the ‘wait for document lock to be released’ functionality in SP2010 workflow. Fingers crossed… 😀
It worked flawlessly! Thank you for documenting this Pieter – saved me some time and consternation. I appreciate it!
In the Do Until action, if you use an update SP item action, won’t it run ~60 times by default? The Do Until action does not escape once Retry equals False.
Hi Ian,
Yes, indeed, but you can increase that 60 to whatever you need.
Hi, thanks a lot for your article.
Just a question : here you are running something in your retrying where you don’t need the output, but do you see a way to identify which output is the correct one ? (or to mix both result ?)
perhaps just duplicating all the element where the output is used with a use if fail ?
You could set a variable inside the loop and then the final value of the variable will be the one that worked. The logic will probably be slightly more complicated than that but it should be okay for a general guideline.
Why does your suggested approach not rely instead on the “Retry Policy” in the “settings” configuration for the action? thanks
That retry policy will only retry so many times sometimes you want to retry for longer.
Thank you Pieter for sharing this method. This is what I was looking for for a long time
Hello. Great article. What is the “‘Compose’ should run after” step after the set variable 2? You configure the run after for set variable 2, then you have a step where you are configuring a run after for set variable 2.
Thanks!
I’m not sure which compose action you are referring to in your comment
It’s in the picture below “Now we can loop with the Do Until action until we stop the retry retrying.”
Hi Pieter, I am confused by the same detail. Your screenshot shows a “Compose” action which should run after Set variable2 was successful, has failed, is skipped, has timed out. Why should this step run after a successful run setting of the variable? I don’t get it and would appreciate, if you could explain. Thanks in advance!
Hi Nina, I just looked at the screenshots in the post but I can’t see Compose steps there.