Throttling in share point

(1) Share

Report

Posted on by RK-03060544-0

Subject: SharePoint Throttling in Power Apps + Power Automate – Best Practices & Environment Impact

Hello Team,

We are currently working on a solution built using Power Apps (Canvas App) with a SharePoint Online list as the data source, integrated with multiple Power Automate flows. Everything is built in default environment in my personal share point with basic m365 license provided by my organization.

Our current architecture includes:
- Power Apps form submitting data to a SharePoint list
- Multiple Power Automate flows triggered on item creation and updates
- Acknowledgement email flow
- Default assignment/status update flow
- Teams notification flow
- Completion email flow

We are frequently encountering SharePoint throttling issues, including:
- Throttle.htm 1033 errors while accessing the list
- HTTP 429 errors in Power Automate flows
- Delays or failures in flow execution when multiple requests are processed

Even with moderate daily volume, throttling occurs due to multiple flows continuously executing in backend and repeated updates per item.

We would like guidance on the following:

1. Would moving this solution from the default environment to a dedicated Premium environment only for client business significantly reduce throttling issues?
2. Are there recommended best practices for optimizing Power Apps + SharePoint + Power Automate architecture to avoid throttling?
3. Is there any official guidance on API/request limits in such scenarios (per flow vs per environment vs per user)?
4. Would consolidating multiple flows into a single flow significantly improve performance and reduce throttling?

Any recommendations or best practices based on similar implementations would be greatly appreciated.

With this throttling issues I'm unable to access any local applications or my entire SPO.

Thank you in advance for your support.

Categories:

Building flows

I have the same question (0)

All responses (7)

Answers (0)

Sort by

How the Connection Limit Works

The SharePoint connector enforces 600 actions per minute per connection. If all four of your flows share the same connection, they share that 600-call pool. Splitting them across separate connections gives each its own bucket, which is a real improvement at the connector level.

Where It Falls Apart

That connector limit is only one of three throttling layers. SharePoint Online also enforces user-level throttling at 3,000 requests per 5 minutes and tenant-level resource unit limits. The Throttle.htm/#1033 page you are seeing is a tenant-level response from SharePoint itself. A different connection does not touch that.

On top of that, if an app keeps exceeding limits, SharePoint can block specific request patterns entirely, regardless of which account is making the call.

What Actually Helps vs What Does Not

Layer	Separate connection helps?
SharePoint connector (600 calls/min)	Yes, each connection gets its own bucket
User-level throttling (3,000 req/5 min)	Partially, only if using a different user account
Tenant-level resource units	No, tenant quota is shared
Throttle.htm full SPO block	No, needs Microsoft Support to lift

Right Order of Operations

Fix call volume first, use separate connections as a secondary measure if needed.

Consolidate four flows into one parent flow with child flows per action. This is the biggest single fix.
Add a loop guard on your "When item is modified" trigger to stop the flow re-triggering itself after a status update.
Implement Retry-After header handling using an Until loop rather than fixed delays.
After the above, split connections across service accounts if you still hit the 600/min connector cap.
If Throttle.htm persists, raise a Microsoft Support ticket. That block requires their intervention.

References

Was this reply helpful? Yes No

Suggested answer

11manish 3,333 on at

Like
a
(0)

Report
Copy link

Link copied!
The fact that you're seeing:

"I'm unable to access local applications or my entire SharePoint Online"

suggests the tenant is hitting aggressive SharePoint throttling thresholds. Once throttling kicks in, Microsoft may temporarily restrict requests across the affected

workload, which impacts both flows and interactive users.

my next investigation recommadation:

Moving to a Premium environment alone will not solve SharePoint throttling.

Consolidate multiple flows into a single orchestrated flow.

Reduce unnecessary SharePoint reads and writes.

Prevent update-trigger loops.

Use trigger conditions and retry policies.

For long-term scalability, migrate the data source to Dataverse rather than SharePoint.

For the architecture you've described, the combination of multiple flows + repeated SharePoint updates is the most likely root cause of the throttling you're

experiencing.

Was this reply helpful? Yes No
Suggested answer

Valantis 6,735 on at

Like
a
(1)

Report
Copy link

Link copied!

Hi @RK-03060544-0,

Custom connectors only read an environment variable at the moment the connector is saved, not at runtime. Microsoft docs confirm this directly:

the connector needs to be resaved every time the variable changes to pick up the new value. That's not viable for a token rotating every 59 mins, which is why TEST/PROD stays stuck on whatever value existed at last deploy.

Fix:

don't put the token inside the connector's security/header config at all. Set the connector auth to a placeholder and pass Authorization as a dynamic action parameter instead. In your flow, add a "Get environment variable value" step right before the action call and feed that into the header.

That reads the live value every run instead of one frozen at save time. Same idea as the APIM/middleware route 11manish mentioned, just lighter weight.

Best regards,

Valantis

✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/

💼 LinkedIn

▶️ YouTube

Was this reply helpful? Yes No
Suggested answer

RaghavMishra 261 on at

Like
a
(0)

Report
Copy link

Link copied!
Hi @RK-03060544-0,

Why this happens

SharePoint Online enforces throttling to protect overall service performance. When too many requests arrive in a short window - which is common when multiple flows fire on item create/update - SharePoint returns HTTP 429 (and sometimes 503) responses. These surface as the Throttle.htm 1033 page and 429 errors in your flows.

Best practices to reduce throttling

Microsoft's guidance for avoiding throttling includes:

Reduce the number of concurrent requests and avoid request spikes (for example, lower the concurrency setting on "Apply to each" loops and stagger flows instead of running many simultaneously).

Honor the Retry-After and RateLimit HTTP headers SharePoint returns, so retries wait the recommended interval rather than repeatedly hitting the service.

Prefer Microsoft Graph APIs where possible, since they generally consume fewer resources than CSOM/REST for equivalent work.

"Decorate" your traffic so calls are identifiable, and review whether service prioritization fits your scenario.

On your specific questions

Moving to a dedicated environment changes Power Platform request limits (see the Power Automate limits documentation), but SharePoint Online throttling is enforced at the SharePoint/tenant level, so an environment change alone won't remove SharePoint-side throttling.

Consolidating multiple flows that act on the same item into fewer flows generally reduces concurrent calls and helps, consistent with the "reduce concurrent requests / avoid spikes" guidance.

Official request limits are documented in the Power Automate limits article.

References

Avoid getting throttled or blocked in SharePoint Online

Limits of automated, scheduled, and instant flows - Power Automate

Found this helpful? Please mark ✅ "Does this answer your question?" so others searching for the same issue can find it quickly. A 👍 on "Was this reply helpful?" or a ♥ Like is also much appreciated!

Raghav Mishra - LinkedIn | PowerAI Labs

Was this reply helpful? Yes No
RK-03060544-0 4 on at

Like
a
(0)

Report
Copy link

Link copied!

Thanks for the responses, flows could be a key point. But do you suggest moving to dedicated environment will resolve the issue.
Even for other functionalities client space is required, isn't it?

Was this reply helpful? Yes No
Suggested answer

Valantis 6,735 on at

Like
a
(0)

Report
Copy link

Link copied!

Hi @RK-03060544-0,

Moving to a dedicated environment alone will not resolve the SharePoint throttling. The throttling you're hitting is enforced at the SharePoint Online / tenant level, not at the Power Platform environment level. A Premium or dedicated environment changes Power Automate request limits, not SharePoint's API limits.

What will actually help:
1. Consolidate your 4 flows into 1 orchestrated flow. Multiple flows triggering on the same item update multiply your SharePoint calls significantly. A single flow with sequential steps for email, assignment, Teams notification, and completion reduces the call volume substantially.

2. Add a trigger condition to your "When an item is modified" flows to prevent self-triggering loops. If a flow updates the item status, that update triggers the same flow again. Add a trigger condition like @not(equals(triggerOutputs()?['body/Status/Value'], 'Processing')) to break the loop.

3. Honor the Retry-After header using an Until loop with a delay, rather than fixed delays or immediate retries.

On the dedicated environment question: if your clients need separate data boundaries, compliance requirements, or you're building a production solution, a dedicated non-default environment is the right governance approach. But do it for ALM and security reasons, not to solve throttling. The throttling fix is in the architecture.

Long term: migrating from SharePoint to Dataverse eliminates SharePoint throttling entirely since Dataverse has much higher API limits and is designed for high-volume Power Platform solutions.

Best regards,

Valantis

✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/

💼 LinkedIn

▶️ YouTube

Was this reply helpful? Yes No
David_MA 14,956 Super User 2026 Season 1 on at

Like
a
(0)

Report
Copy link

Link copied!
Adding to what others have said, I don't see that anyone has mentioned the following:

When you refer to your "personal SharePoint" and based on the link shown in your screenshot, it appears that you may actually be using your OneDrive for Business site rather than a SharePoint team site for this solution. I assume the app has been shared with other users in your organization.

If that is the case, I would recommend creating a dedicated SharePoint site and moving the components currently stored in OneDrive to that site. You should also add the users of the app as members of the SharePoint site. This will provide a more appropriate location for a shared business solution and can help avoid potential permission-related issues in Power Apps and Power Automate.

It would also be helpful if you posted additional details about what your flows are doing. Without seeing the workflow design, trigger configuration, and the actions being performed, it is difficult to determine what may be causing the throttling. Based on your description, the throttling could be related to the overall flow design rather than the environment itself.

Was this reply helpful? Yes No