Hit Power Automate Run Limits With No Licence Budget: Recovering SharePoint and Teams Automations

Why are SharePoint and Teams flows failing when nothing has changed?

Usually something has changed, just not in the flow designer. The Power Automate rights included with most Microsoft 365 plans cover standard connectors such as SharePoint, Teams, Outlook and Approvals, and every action a flow runs counts against Power Platform request limits tied to the licence of the flow's owner. Microsoft also assigns flows a performance profile from that licence, and flows running on Microsoft 365 seeded rights sit at the lower end. When volume grows, a list gets busier, someone adds steps or a new flow loops on itself, the same flows start running slowly, queueing, or being throttled, and Microsoft documents that flows which stay over their limits for a sustained period can be slowed or turned off.

The specific allocations, performance profiles and enforcement rules have changed several times and are still being revised, so we do not quote numbers here. Read the current Microsoft documentation on Power Platform request limits and allocations and on Power Automate limits and configuration before you decide anything, and record the date you read it.

How are Microsoft 365 request limits different from Dataverse 429 throttling?

They are different ceilings with different fixes, and treating one as the other wastes the time you do not have. Read the flow's run history and the raw output of failed actions before changing anything.

What should you do in the first 48 hours?

Stop the damage, protect the business deadline, then diagnose. The first two days are not for rebuilding anything.

• Turn off runaway triggers. A flow on "When an item is created or modified" that updates the same item retriggers itself; a Teams trigger on a busy channel or a recurrence every minute can burn requests all day. Turn those flows off, or add trigger conditions, before anything else.
• Give finance a manual fallback for payroll approvals now, not when the flow fails on the day: who approves, in what order, where the evidence is kept (for example an approval column on the SharePoint list plus a dated sign-off email in a named folder), and a control total checked before payroll is released.
• Freeze changes to the affected flows except for the recovery work, so you are not chasing a moving target.
• List every flow that touches the payroll process and its owner, and mark which ones the payroll date depends on.
• Tell the payroll owner and IT which date the fallback will be used if the rebuild is not proven by then.

How do you find the flows that are burning requests?

Request usage is attributed to the flow owner's licence, so start with the owners whose flows are being slowed and work down to individual flows. You are looking for a small number of flows doing most of the work, which is the usual pattern.

• Use the Power Platform admin center and Power Automate analytics for run counts and action usage per flow, and check the flow details page for performance warnings. Microsoft has been reworking these reports, so use what your tenant currently shows.
• In each suspect flow, open recent runs and count actions per run: an apply to each over a few hundred list items with eight actions inside is thousands of actions per run.
• Sort by runs per day as well as actions per run. A small flow triggered on every edit can cost more than a large flow that runs nightly.
• Look for self-triggering loops, polling recurrences, retries on throttled actions and pagination that reads whole lists, because retries and pagination count as actions too.
• If you already run the Center of Excellence Starter Kit, its inventory gives you flows and owners across environments. If you do not, do not install it this week.

How do you rebuild a flow as a scheduled batch with OData filters and trigger conditions?

Most failing SharePoint flows run once per item change and do a little work each time. The rebuild turns that into fewer runs that each process a filtered set of items. Payroll approvals rarely need to react within seconds; a schedule a few times a day, aligned to the approvers' working pattern, is usually enough and is far cheaper in requests.

Where an automated trigger is genuinely needed, add trigger conditions in the trigger settings so the flow starts only when the relevant column has the relevant value, for example only when Status is Submitted, and have the flow write a marker column that the condition excludes, so its own update cannot start it again.

• Replace the per-item trigger with a Recurrence trigger at an interval the process can live with.
• Read with Get items and an OData Filter Query on indexed columns, for example items where Status is Submitted and Modified is later than the last successful run, and use Top Count and pagination deliberately rather than reading the whole list.
• Store the last successful run time in a configuration list item, update it only when a run completes, and use it as the filter boundary so a failed run is picked up by the next one.
• Index the columns you filter and sort on before the list grows; on very large lists adding an index can itself be restricted.
• Group the work: one approval per batch, department or pay group with a summary and a link to the filtered view, rather than one approval per employee line.
• For large SharePoint lists, the throttling advice in our 429 guide applies as well.

How do you cut the number of actions each item costs?

Every action counts, including conditions, variables, composes, retries and pagination, so the cheapest action is the one that is not inside a loop.

• Use Select and Filter array on the whole result set instead of an apply to each that appends to a variable item by item.
• Stop calling Get item inside a loop when Get items already returned the columns you need.
• Update many items in one call with SharePoint REST $batch through Send an HTTP request to SharePoint, splitting large sets into several batches. Check current Microsoft documentation for batch size limits and handle the per-item results in the response.
• Post one digest message or adaptive card to Teams per batch instead of one message per item.
• Move calculations into expressions in a single Compose rather than a chain of Set variable actions.
• Remove steps that only log to another list on every item; log once per run with counts and a link.

When should high-volume work move to a script instead of a flow?

When a job is essentially bulk data movement with no human step, such as nightly updates to thousands of list items, archiving or reconciling against an export, a script is often the right tool. PnP PowerShell or Microsoft Graph, run on a schedule in Azure Automation or from an Azure Function, can read and update SharePoint in batches without consuming Power Automate request allocations. The flow keeps the human parts: the approval, the Teams notification and the audit trail.

This is not free of cost or governance. Azure consumption is a separate budget line, usually small but not zero. The script runs under an app registration with certificate authentication and permissions that your security team has to approve, scoped to the sites it needs where possible. It needs logging, alerting on failure and a named owner, or it becomes the next undocumented automation. And do not spread work across extra user accounts purely to multiply allocations: check the Microsoft licensing terms first, because that pattern can create a compliance problem. For Dataverse-heavy jobs, the 429 guide explains when Azure Functions or a scheduled Web API job is the better home.

What does a two-week recovery plan for payroll approvals look like?

The plan below assumes one experienced Power Automate developer, a payroll owner who can make decisions quickly, and a payroll date at the end of the second week. It keeps the manual fallback live until the rebuilt flow has been proven, so payroll never depends on untested automation.

When do you need outside help to hit the payroll date?

In-house is fine when someone on the team has built batched, filtered flows before, owns the flows involved and can give the recovery most of their time for two weeks. Bring in help early, on day two rather than day ten, when any of these is true.

• Triage is not finished by the end of day two, or nobody can say which flows are consuming the requests.
• The flows were built by someone who has left, run on their connections, or are undocumented. Taking them over safely is covered on our Power Automate consulting page.
• Nobody in-house has used REST $batch, trigger conditions or the OData filter syntax in production.
• The fix needs an app registration and Azure Automation, and the security approval will take longer than the plan allows without someone preparing it properly.
• The failures are actually Dataverse 429s or a mix of limits, which our Power Automate and Power Platform support service diagnoses symptom by symptom.
• Finance needs reconciliation controls and alerting so a silent failure cannot skip an approval, which the same support page covers.

How does Solzet help with a Power Automate recovery like this?

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.

For a request-limit recovery that means fixing the automation you already pay for before anyone suggests new licences. Our senior consultants and full-stack developers, with 8+ years of Dynamics 365 and Power Platform delivery and working remotely from Yerevan, Armenia, can run the triage with your team, rebuild the payroll-critical flows as batched and scheduled runs, move bulk jobs to PnP PowerShell or Azure Automation where it is justified, and hand over documentation and alerting. When a process has outgrown SharePoint lists altogether, we will say whether it belongs in Dataverse, in Dynamics 365, or in a custom application you own.