Migrating SharePoint alerts to Power Automate before the July 2026 retirement means building more flows against SharePoint lists than most tenants have run before, and that makes it worth knowing the limits in advance rather than discovering them mid-migration. The tables below cover the run, trigger, and connector limits most relevant to notification-style flows built on the SharePoint connector.
Flow Run Limits by Licence Type
| Licence | Included flow runs | Notes |
|---|---|---|
| Power Automate for Microsoft 365 (included in most M365 plans) | Per-user monthly allowance shared across all flows the user owns | Sufficient for typical alert-replacement scenarios |
| Power Automate per user plan | Higher dedicated allowance | Needed for premium connectors or high-volume automation |
| Power Automate per flow plan | Dedicated allowance for a specific flow | Best for one critical flow needing guaranteed capacity |
SharePoint Connector Trigger Behaviour
| Trigger | Polling interval | Typical use in alert migration |
|---|---|---|
| When an item is created | Near-real-time to a few minutes, depending on connector load | Replaces an immediate "new item" alert |
| When an item is created or modified | Near-real-time to a few minutes | Replaces most general-purpose change alerts |
| When an item is deleted | Polling based, typically a few minutes | Replaces deletion-notification alerts |
| Scheduled (Recurrence trigger) | Configurable, minimum interval depends on plan | Replaces daily or weekly digest-style alerts |
What Happens When a Flow Is Throttled?
SharePoint connector actions are subject to the same underlying SharePoint Online throttling as any other API-driven request. A flow that queries a very large list, or one that fires very frequently against the same site, can be delayed or temporarily rejected during peak load. Power Automate automatically retries throttled requests using an exponential backoff, so an occasional throttle event usually just means a delayed notification rather than a failed one. Flows that repeatedly hit throttling are usually querying too broad a scope; narrowing the trigger's list view or adding a filter earlier in the flow reduces the load per run.
List and Library Size Considerations
- Triggers scoped to a specific list view perform better than triggers scanning an entire unfiltered library
- Very large libraries (tens of thousands of items) can slow trigger polling; a filtered view reduces the amount of data the connector has to evaluate each cycle
- Flows built against a list already near SharePoint's list view threshold benefit from the same indexing and view-scoping practices used to keep the list itself responsive; see the SharePoint list view threshold reference for the underlying limits
Connector Request Limits
| Scope | Behaviour |
|---|---|
| Per-connection request rate | Capped per minute; heavy parallel flow activity against one SharePoint connection can hit this before hitting per-user run limits |
| Concurrent flow runs | Configurable per flow, with a default concurrency limit; high-volume trigger events queue rather than run in unlimited parallel |
| Action timeout | Each action in a flow has a maximum execution time before it is marked as timed out and retried or failed depending on configuration |
Practical Guidance for an Alerts Migration
- Group similar alerts into shared, parameterised flow templates rather than building one flow per alert, which keeps the total flow count and per-user run consumption manageable.
- Scope triggers to a filtered list view wherever the original alert only cared about a subset of items.
- Use scheduled (Recurrence) triggers for anything that was a digest-style alert rather than trying to force a per-event trigger to batch itself.
- Monitor the Power Automate admin centre's run history during the first few weeks after migration to catch any flow approaching its licence's run allowance before it becomes a problem.
For the full retirement timeline that is driving most of these migrations, see the SharePoint alerts retirement announcement. For a side-by-side look at when Power Automate is the right tool versus the simpler SharePoint Rules feature, see SharePoint Alerts vs Power Automate compared.
See how Report Master audits SharePoint activity before you decide which lists need a flow at all.