Having an issue here where my flows that are active for more than 28 days are automatically getting deleted. I am running an approval system and some of these flows need to be running for a longer period of time. So when an approver eventually responds, nothing happens since the flow is no longer available. Is there any work around for this?
That message is just for the run logs of individual flows. Any history older than 28 days is automatically deleted. If you want to keep it longer than that you'll need to create something to back up the logs to another data source. But the deletion of those logs shouldn't affect flows that are currently running. Flow instances will automatically time out after 30 days and the history isn't recorded until the flow finishes running. So, an approval that runs for 28 days will have another 28 days in the history log until the log is deleted. If you have approvals that take longer than 28 days you'll need to redesign the flow in some way so an individual approval request never runs for more than 30 days.
Thanks @Pstork1. Any tips on how this can be avoided? I am using a flow where the approver must respond before it moves onto the next. The total pending duration can take a total of more than 30 days. Honestly can't think of another way other than educating the business to approve the request asap.
The key to doing this is to either redesign the flow to take advantage of recurrence or redesign it to be a state machine flow. Both break up the flow into smaller sub flows so no flow will run for more than 30 days.
For recurrence you need to create each approval as its own flow with a recurrence trigger set to some duration like one day. Then use a trigger condition to decide which flow to invoke based on the status recorded in the item being approved. Each day one of the approval flows will start based on the status and whether there is an approval pending. As approvals are completed the current status will be recorded. The next day the next approval will start. Each individual approval can run for up to 30 days.
The state machine pattern is similar, except there is a central flow that gets invoked as each approval is completed. Based on which approval was completed it triggers a new approval flow. Here's a video that explains the state machine flow design. Microsoft Power Automate Tutorial - State Machine - Part 1 - Bing video
Do you know if the 30 days max run time limitation impacts child flow runs as well? Let's say I have Flow A that triggers Flow B as child flow. Now Flow A runs for 25 days and as a last step it calls child Flow B that will run for another 25 days. Flow A didn't finish as it expects answer to come from Flow B, but Flow A will be terminated after 30 days. As the Flow A is terminated, will it terminate child Flow B as well?
Yes, it affects child flows as well. Its the flow session that is limited to 30 days. Since the parent and child run in the same session they will both time out after the 30 days is up. Child flows triggered from HTTP would be different since they are triggered independently and run in their own session. But in that case you can't return a value to the calling flow since it might have timed out. If you watch the State Machine video I referenced that is how they get around the 30 day limitaton.
Unfortunately, state machine flows are not suitable for my current needs. My flow has multiple approvers and after every approver, their responses (comment, date, email etc.) are recorded into variables within the flow. These variables are then passed along to the next approver (in the form of a HTML table through email) within the flow where they can see a log of all the other approver's details and responses. Using state machine flows basically restarts the flow after each approver, and will wipe away all the data recorded. I could have the data recorded into the Sharepoint list itself, but it would mean I would need to add multiple columns.
Its almost 2022, and I'm quite surprised to see that Microsoft still has not extended the limit for whatever reason.
The problem is that each running flow requires capacity to maintain. Increasing the timeout on flows would exponentially increase the amount of system resources required to maintain the state. I don't expect you will see that limit change. Your only choice is to redesign the workflow to store information in a data source rather than the flow memory.