What it does

Cloud flows run inside a set of published limits covering how long a run lasts, how many actions a definition can hold, how many items a loop can process, and how many Power Platform requests an account can make. Exceed a throughput limit and the platform slows the flow down rather than failing it; stay above the line long enough and the flow gets switched off.

Key facts

• A single run can last 30 days, and run history is retained for 30 days, both measured from the run's start time. Pending approvals time out at the 30-day mark.
• A flow definition allows 500 actions, eight levels of nesting, 250 variables, 25 Switch cases, 8,192 characters per expression and 80 characters in an action name.
• Apply to each processes 5,000 items on a Low performance profile and 100,000 on the others. Do until defaults to 60 iterations and caps at 5,000.
• Every trigger and action generates one Power Platform request, including built-ins like Compose and Initialize variable. Successful and failed actions both count; skipped ones don't. Retries and pagination requests count too.
• Requests are limited to 100,000 per five minutes, and per 24 hours by performance profile — 10,000 for Low, 200,000 for Medium, 500,000 for High, 10,000,000 for Unlimited Extended. Microsoft describes the daily figures as approximations, not guarantees.
• The performance profile comes from the flow owner's licence. Low covers free, Microsoft 365 and Plan 1 licences; Medium covers Plan 2, Premium and child flows; High covers Process and per-flow. If the owner leaves the organisation, the flow drops to Low.
• Message size is capped at 100 MB, or 1 GB where the action supports chunking. Synchronous inbound and outbound HTTP requests time out at 120 seconds.
• Flows that fail continuously, or are consistently throttled, are switched off after 14 days. Flows with no trigger activity for 90 days may be switched off unless the owner holds a premium or capacity licence.
• Throughput limits are calculated per flow version on sliding windows, so publishing an update resets them.
• Connector-level throttling is separate and usually bites first, returning a 429 with a retry-after hint.

When to use / skip

Design against these limits on anything processing more than a few hundred records or running more often than hourly — that's where they turn from trivia into project risk. For a flow that fires twice a day and touches five records, the limits are irrelevant and modelling them is wasted effort. The number worth watching on almost every engagement is the daily request count, because it's driven by the owner's licence rather than by anything visible in the flow, and it's the one that surprises people after go-live.

Configuration decisions

• Who owns each production flow, since the owner's licence sets the request ceiling and the owner leaving drops it to Low.
• Whether high-volume work should be split across multiple flows, debatched with Split On, or moved to a Process-licensed flow.
• Whether the design can be changed to use fewer actions — bulk operations and Select instead of loops is the usual lever.
• Whether monitoring watches request consumption via the Analytics tab and the admin centre, or just waits for throttling to show up.
• Whether long-running approvals fit inside the 30-day run duration, or need a different pattern.

Gotchas

• The request limit is per account, not per flow. One badly behaved flow throttles every other flow the same user owns.
• Ownership transfers change the performance profile silently. A flow that ran fine under a Premium owner starts throttling when it's reassigned.
• Retries count as requests, so a flow failing against a dead endpoint consumes its allocation faster than a working one.
• Throttling shows up as flows running slowly, not as errors. Clients report "it's gone sluggish" and nobody thinks to check limits.
• Publishing a new flow version resets throughput counters, which makes intermittent throttling look like it fixed itself.
• Run history only goes back 30 days. Anything the client needs for audit or compliance has to be logged out to Dataverse or elsewhere as the run happens.
• The 500-action limit is a hard stop, but flows get slow to open and edit well before it.

Consultant notes

• Model expected request consumption during design on any high-volume process, and put the number in the design document. It's the cheapest way to avoid a difficult conversation three months after go-live.
• Production flows should be owned by a service account with an appropriate licence, not by whoever built them. Make this part of the ALM standard.
• If run history is being treated as an audit trail, correct that early. Thirty days is not an audit trail, and the remediation is a logging pattern, not a setting.
• Connector limits usually bind before platform limits. Check the specific connector's reference page rather than assuming the platform figures apply.
• Process licences raise the ceiling and can be stacked on a single flow for more daily action entitlement. Worth pricing as an option against redesigning a flow, but check current licensing before quoting anything.

---

Recheck against the current limits page each release wave — these numbers move, and the licensing transition figures especially.