Photo by Alex Blăjan on Unsplash
Microsoft Flow has a built in timeout of 30 days for any running Flow (Logic Apps has 90 days), which for most scenarios is not a problem.
However, there are business processes that might run longer than 30 days, and I’ll address two common scenarios and how to overcome them.
See https://docs.microsoft.com/en-us/flow/limits-and-config for details on Flow limit and see https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-limits-and-config for limits on Logic Apps.
Scenario 1: Any single action will never last 30 days, but the total Flow might
Let’s imagine you have 5 consecutive actions in your flow, where there is no chance that any of them will run for more than 30 days. For example 5 consecutive approval steps. The way to work around this is to create one flow per approval, and then have them call each other as they go along.
To illustrate the steps I have created two flows. One named “Flow – Initial” and the other “Flow – 2”.
I’ll start with the second flow, as this will be called from the first.
This takes a HTTP request as input. In this case two parameters, a title and description, which is used in the an approval action. After you save this flow, copy the POST URL, which you will need in the initial flow.
The initial flow takes input from the user, and then calls the second flow, a pattern you can use to continue calling the third flow etc..
Scenario 2: A single action might take more than 30 days
Again, let’s take a look at an approval flow. You start an approval task i a Flow, but it could take more than 30 days before someone accepts or rejects it.
Again you need one initial flow which kicks it all off. This can be a Flow button, or any other trigger which grabs the initial input.
The key is to generate a JSON object with all the needed data which you can use in the flow with the actual business logic.
I’ll use Flow – 2 as my staring point, and the idea is to have this Flow call itself as long as needed until the approval is accepted or rejected.
First I’ll access the settings for the Approval action.
As I mentioned at the beginning, the default max timeout is 30 days in Microsoft Flow. The idea is to restart the flow if it times out within this boundary. You don’t have the possibility to perform actions if the flow itself times out, but we can act on when a single action times out.
If you set the action timeout to 29 days it’s guaranteed to timeout before the whole flow times out. To test it out you can set the timeout lower, for example 15 minutes (PT15M).
After the approval action add an HTTP action with the same URL as the HTTP trigger and the same Body – which is the data you passed in with a title and description. Next open the Configure run after option.
Uncheck the is successful option, and check the has timed out option.
The effect of this is that if the Approval was approved or rejected within 29 days, then all is good. If not, the approval request will actually be removed and a new one is issued by re-running the flow.
Of course, you might want to add e-mail alerts or other logic when an action times out before you re-try it. You could also add a parameter in the initial JSON data saying which run this is, and then increment per run if you want to re-try X number of times. Either way you should have a staring point to continue building out the logic you need for long running flow.
Summary
Even though a Microsoft Flow times out after 30 days, there are ways to architect yourself around this by using multiple flows which either call on each other, or call on themselves. Or if a timeout within 90 days works for you, you could move your Microsoft Flow to run as a Logic App instead.