This is a very simple one. If you have a flow or logic app that has a lot of SharePoint actions – an Apply to each loop with a lot of iterations that contains a few SharePoint actions for example, then you might have experienced being throttled.
When you get throttled the API will respond with status code 429 (too many requests) or 503 (server busy). Power Automate and Logic Apps will see these as unsuccessful and fail the action.
If you don’t handle this properly in your workflow and continue making API calls regardless – which will happen in a loop – then you run the risk of this happening:
The screen shot above is from here: https://learn.microsoft.com/en-us/sharepoint/dev/general-development/how-to-avoid-getting-throttled-or-blocked-in-sharepoint-online
When you receive either of these error code, you will also have a header in the response called Retry-After with an integer value that represents the number of seconds SharePoint is asking you to wait before retrying.
So to avoid the Microsoft ban-hammer, we’ll use this Retry-After header to handle throttling.
Add an Until/Do until loop. This can be nested inside another Until or a For each/Apply to each loop.
Your SharePoint action is inside there, and you want this loop to continue until the status code is not 429 or 503. To do that we need an “advanced” condition:
@not(or(equals(outputs(‘Create_item’)?[‘statusCode’], 429),equals(outputs(‘Create_item’)?[‘statusCode’], 503)))
This means that if this action succeeds on the first go or fails with any other code than 429 or 503, it won’t repeat the loop. As these two codes are the only ones with Retry-After in the headers, then we need to use the same condition in the next action:
The rows in the condition action make complex conditions a bit easier to develop and understand than in the Until loop, but in this case it’s the exact opposite of the condition in the loop: If the status code is 429 or 503 then do a delay, otherwise don’t.
The Count input is the value of the Retry-After header: outputs(‘Create_item’)?[‘headers’]?[‘Retry-After’]
This will cause the loop to wait for the number of seconds specified in the Retry-After header. As it’s also the last action in the loop, the next thing that happens is the loop starts again and it’ll have another try.
If it goes down the No/False branch then there’s no delay, and because the HTTP status code from the SharePoint action wasn’t 429 or 503 then it won’t repeat the loop and simply move on to the next part of your flow.
So, handling throttling in Power Automate and Logic Apps is quite straight forward. We don’t need any knowledge of what the rate limits and quotas are, only the fact that the action fails and tells us to wait for some number of seconds is enough to gracefully handle the situation.
William's IT Blog 🍉 
Thanks for taking time to write this post. This seems like a simpler and far more understandable way to handle these “time-out” conditions.
Related to this, I’d like know more about Power Automate “Retry Policy” which is hidden away in the action’s settings.
Best wishes,
Ellis
LikeLike
Retry policy can be used to retry a failed action automatically, but it’s not possible to pass dynamic content into it. So while you could probably use it effectively to get past throttling issues in SharePoint, your flow will be much longer running and you still run the risk of getting banned if your policy retries too quickly too often. If you want to know more about the retry policy in general, there is good documentation on the Microsoft website.
LikeLike