Hi,
Since approx. 2 weeks ago, some of my flows are reporting this message:
"Your flow's performance may be slow because it's been running more actions than expected since 17/09/2020 17:57:40 (2 weeks ago). Your flow will be turned off if it doesn't use fewer actions.Learn more"
After several tests, I can see the problem seems to be the "Apply to each" action. Apparently, after 5000 iterations, the flow stucks there for several hours so I have to cancel it.
I've checked the Limits
https://docs.microsoft.com/en-gb/power-automate/limits-and-config
Looping and debatching limits
These are limits for a single flow run. For daily limits, refer to the requests limits and allocations.
Apply to each items - Office 365 and Free licenses | 5,000 | You can use the filter action to filter larger arrays as needed. |
Apply to each items - Plan 1, Plan 2, Per User, and Per Flow licenses | 100,000 | You can use the filter action to filter larger arrays as needed. |
I have a "Per User" plan so I would expect to be able to run 100,000 actions per flow, not 5,000.
I tried to split the Apply to each into batches of 2000 and still the same issue.
Furthermore, the same flows have been running fine for several months.
Anyone having the same issues lately? Are my assumptions above correct?
Any comments will be much appreciated.
Thanks
If you’re getting throttling or daily action limit issues & you have flows with loops running conditionals, SharePoint list, or Excel table actions, then you should…
-Use Filter arrays outside the loops to pre-filter based on the condition criteria
-Use SharePoint batch actions: https://powerusers.microsoft.com/t5/Power-Automate-Cookbook/Batch-Update-SharePoint-List-With-External-Data/td-p/1365410
-Use Excel batch actions:
https://powerusers.microsoft.com/t5/Power-Automate-Cookbook/Excel-Batch-Delete/td-p/1634375
I've run into the exact same issue. A flow running perfectly for a year has suddenly started stalling while copying around 10 text files (5kb per) from the file system to sharepoint. It's become utterly useless for my purposes now.
I having the same issue on after per user plan licence on "apply to each" action
I contacted Microsoft directly on this issue and was told that indeed the flow was getting put into the timeout box. They won't explicitly tell you that the flow was throttle until your on the extreme end. Every item in your flow counts towards an action, so I would double check the amount of times your flow is running. As a per user you are allowed 5000 actions in a 24hr period. So if you have a Apply to Each, the apply to each itself counts as one, and each flow action counts as one action. So if you have 6 actions inside an apply to each and that apply to each runs 25 times, you have 25*6+25 as the amount of actions for that particular apply to each. Then ofcourse you have the number of times that specific flow runs in a 24hr period. This is what Microsoft told me.
I had a flow that was working a backlog of exporting emails to sharepoint. I was repeatedly getting stuck in a throttled area where I would have a flow run for 8-24hrs then complete successfully seemingly having no pattern towards what it would get stuck on. They confirmed on the back-end it was indeed getting throttled.
Unfortunately "per user accounts" do not have analytics to determine if you are above your limits. Do the math, EVERY line in your flow counts as an action.
In addition to actions, you also have a 1GB per day memory usage limit, this cannot be tracked anywhere in the Per User account.
Sucks, but it is what it is. My problem was I was hitting both limits. My flow was fairly simple and I still hit the 1GB limit (at around 2-3GB). Limit your actions, and limit your runs.
Hi @DanielPuckett , perhaps a miscommunication here -- the question is why flows which were designed within the very clear specifications of our licenses are now being turned off for being outside of the license limits.
It's really great that you've been able to improve your flows but it doesn't quite answer the question at hand
Flows are all executed on shared resource machines and it just makes sense that resource hogging flows are penalized and slowed down in an effort to have their owners write them more efficiently.
I had a throw away prototype flow that was essentially polling the Graph API 17,000 times per day (yes, there is a special hell reserved for authors of such nonsense). After a few days the flow was put into some kind of penalty box and became terrible slow and unresponsive.
Then I re-wrote it to register a notification subscription with the Graph API via a custom connector and Azure AD Authentication app and is now 100% event driven and is VERY responsive.
Perhaps this is an opportunity to examine why you are iterating though so many items? Perhaps your data needs to be moved to something queryable like a SQL database?
Dealing with this as well, have had a flow running fine for the entire year and now it's unstable and taking hours for each loop making the flow practically useless.
Just wanted to comment that I started having the same issue on the same date.
My flows still appear to be running but they are taking 5 - 10x longer than before.
WarrenBelz
146,660
Most Valuable Professional
RandyHayes
76,287
Super User 2024 Season 1
Pstork1
65,999
Most Valuable Professional