Retry Flows

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.

retry pattern

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.

Process with action


In the retrying scope I’m setting a variable to true, so that I can check if we are retrying or not.

Start retrying

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.

send email retry

Now we can loop with the Do Until action until we stop the retry retrying.

Do Until set run afters

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.

Tru or fals retry

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.

Next steps

By Pieter Veenstra

Business Applications and Office Apps & Services Microsoft MVP working as a Microsoft Productivity Principal Consultant at HybrIT Services. You can contact me using

19 thoughts on “Retry after failures in Power Automate”
  1. 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

  2. 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

  3. 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… 😀

  4. 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.

  5. 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 ?

    1. 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.

  6. Why does your suggested approach not rely instead on the “Retry Policy” in the “settings” configuration for the action? thanks

  7. 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.

  8. It’s in the picture below “Now we can loop with the Do Until action until we stop the retry retrying.”

  9. Hi Pieter, I am confused by the same detail. Your screenshot shows a “Compose” action which should run after Set variable2 was successful, has faild, is skipped, has timed out. Why should this step run after a succesful run setting of the variable? I don’t get it and would appreciate, if you could explain. Thanks in advance!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.