Power Automate, like any other tool, has limits, and one of them is that it can only run for 30 days.
There are Flows and processes that require more than 30 days, like waiting for approvals, answers and other types of "waiting", so I see all the time people asking how to run the Flow for more than 30 days.
I don't like the solutions that I see so I decided to create a reference that I can update over time with new items, but start with the most common issues that I see and their solutions.
The answer to the question should be "you can't", but since there are better ways to approach this, the better answer is "you can with a change in strategy".
I will show you the "bad smells" on your Flow and how you can spot them and fix them.
Wait for something to happen
I saw this question in the Forum:
I currently have a powerapp where users create jobs that they take ownership of via email. I want to create a system where, when the job is created, a power automate flow will be scheduled to send them an email a month from them creating that job. Is there a way to do this? I basically need separate instances of a flow to run based on when the job is created.
There are multiple variations of this but it always boils down to: I have something that needs to happen in a month, so I would like for Power Automate to wait until then.
This is a huge "bad smell".
Power Automate should run and finish as fast as possible, so if you have something that needs "waiting", then you should understand right away that something's up.
A better strategy for this would be to:
- Store the request to a SharePoint list, excel or anywhere that Power Automate can access it.
- Stop the Flow
That's it.
Save all requests to a "bucket".
Then create a scheduled Flow with the "Recurrence" trigger, for example, that checks where you stored the request and validates if it's time to parse it. You can even fetch the information using "OData" queries so that you only get the information you need.
Then process the few items that need to be processed and finish.
You have 2 Flows that start and end as fast as possible and the requests can wait for as long as needed. For bonus points you can even have the "waiting time" in a separate list, excel, etc. that you can change when needed without having to rebuild the Flow.
If you find yourself in a situation where "I need to wait for X", don't put "Sleep" actions in your Flow and wait for it to happen. Log the request and check if they are "ready to process".
The biggest advantage in my opinion is that you separate the responsibility, meaning that if you have another process that can trigger the "waiting request", then you can have it put it in the list and the "process request" part of the process doesn't change.
Waiting for Approvals takes more than 30 days
The "Approval" action doesn't have a limit per se, but it follows Power Automate's 30-day limit. It will trigger a failure if it runs past that time, but there are approvals that could take more than 30 days. So what to do?
To solve this we need to be a bit more strategic. First we need to catch the "failure happening", meaning that we need to catch when the Flow "timeout" occurs. To do that you can use the "Try catch finally" strategy. This way you will know when the timeout occurs.
Then we have a few options:
- Just send an email saying that the approval reached its deadline and it needs to be restarted (not good but it could be a solution in your case)
- Trigger it again (better approach)
We could use the same strategy as the previous section. So if we need an approval, we could save it somewhere first.
We store the request for the approval somewhere with all its data.
Then you could have another Flow that triggers the approval based on that table, so that you keep control on what's "in flight". This is already a huge win because you can have a dashboard with all that is happening, whereas before you would be flying blind. You can see what approvals are waiting, expired or finished.
Then if the approval fails because 30 days have passed, you just need to catch it and update the table. This way you have the option of what to do next. For example, you can have a Flow that will trigger only for expired ones and trigger a new one but with a different text, for example.
Separate responsibilities. One thing/workflow/Flow triggers the notifications and another processes them.
Like before, this would make things a lot more scalable and allow you in the future to upgrade things without having to change everything.
Checking things periodically
Another case that people do is to trigger a Flow that has an "Apply to each" action or worse a "Do until" action that will check something, and if it didn't happen, wait X time.
This is a horrible use of your Power Automate capabilities.
In this case a nice "Recurrence" trigger would do the job nicely. You can have a list of "stuff to check", the Flow triggers, checks, logs the findings and then stops.
The Flow should run as fast as possible and always finish at a time you can predict.
This way you can predict more or less how long the Flow will run, and if there are any deviations, then you will know that something's wrong.
Final Thoughts
So the idea is always the same:
- The Flow should always run as fast as possible and finish when you want
- Separate responsibility between multiple Flows
- Don't wait for stuff to happen inside the Flow. Have it check once in a while.
If you apply this you will save yourself a lot of issues as well as make your Flows run fast and in a predictable way.
So if your question is "how to extend more than 30 days", then you know you have to re-think the process. That's your "bad smell" trigger.
Photo by Ken Suarez on Unsplash
No comments yet
Be the first to share your thoughts on this article!