Today I want to answer the common question about long-running Flows. “How can I configure Flow to run for more than 30 days”. But as we already learned in the past, just because there’s a limitation doesn’t mean we can’t do it. It’s all about strategy, so let’s check an example and how to do it.
First, let’s define a straightforward approval process for a development project idea that comes to the IT department to be developed.
As you may have noticed, the overall process is super simplified for what happens in some companies, but it serves our purpose now.
The overall process is based on approvals. Each step goes to a different department to check if everything is correct to go forward. The Finance department to understand if there’s money to support it, the management to understand if there are resources to develop it and if the requirements are correctly defined. After all this, the project is sent to development.
Let’s look at two strategies to develop this automation.
The common strategy
The standard strategy is to use the “Approval” action that sends an email with approval buttons to a person or group of people. When someone approves it, another approval process starts until the end, when the project is ready to be implemented. You can even automate the rejections where an email is sent to the person to provide information.
The overall process makes sense, but it has a huge issue. Since we’re waiting for people to do the actions, the Flow may take some time to run until the end. Remember that the Flow will stop on the “approval” action and wait for the answer. For example, if people book meetings to understand some parts of the process before approval, or simply because people are on holiday, a simple approval can take more than one week. Multiply with all actions, then you’re close to the 30 days limit, and the Flow will fail.
If you run into this limitation, your first instinct is to google:
“How to make a Flow run more than 30 days?”
But this is the wrong question in my opinion. Let’s look at a better strategy.
The better strategy for long-running Flows
The better strategy here is divide to conquer. I’m not too fond of long-running Flows for several reasons:
- You increase the probability of crashes.
- You make them more complex
- They are harder to restart if they fail in the middle of the process.
In the above case, think about if the Flow fails in the middle of the process. What can you do? Start the overall approval process again? That’s not good since we will confuse and frustrate the people that aprove it since they need to do their job twice.
But what about if you have multiple Flows and not only one? For example, one per step of the process. Power Automate allows us to call child Flows so we can have a Flow that kicks the process, waits for one approval, and then either finishes with the rejection or calls another Flow for “step 2” of the process. This way:
- Your Flows will run fast
- You can easily restart a step in case of a failure without the need to start the whole process
- Each Flow will take 30 days, so you’re multiplying the time you have for people to answer.
- Even if it takes more than 30 days, you can restart the process by calling the Flow step again.
Let’s look at a potential skeleton of the process.
The Flow won’t stop to wait for the Child Flow to finish, so when we call the “Run Child Flow” action, the Flow will finish. We get the first 3 points with this strategy, but what about the last one? We want to restart the process only if there’s a timeout in the approval so we can do the following:
Next, we need to tell Power Automate to only run when there’s a “timeout,” meaning that the action ran more than 30 days. Here’s how to do it:
Finally, let’s tell Power Automate to run only after a timeout.
With this, your Flow will run “normal” when someone answers in time to the approval process but repeats it when someone ignores or doesn’t reply in time.
I always like to mention that the above strategy won’t be the solution for inaction for people. The system will only work if people approve or reject it, but at least you’ll have a resistant strategy to, even after a timeout, you can restart the process at a specific step and not from the beginning.
I need to find a bell to ring every time I say this, but it’s all about strategy, so as you can see above, with a few minor tweaks, you can have Flows that resist the 30 days rule without being long-running Flows.