By Michael Branson

Nightly ERP-to-CRM syncs drop records with no way to tell whether they failed, retried, or were never picked up. Security reviews block flows weeks before go-live because the connection runs on a departing employee’s account. One side argues for a custom build, the other argues Power Automate already covers it, and the argument runs for a quarter without either side writing down a single number. This page is written to end that argument in an afternoon. It compares Power Automate against a custom integration on the points where they genuinely differ, using Microsoft’s own published limits, and it says plainly where the answer is a custom build.

What measurable thresholds put an integration past Power Automate and into a custom build?

This is not a capability question and it is almost never settled by a feature list. It is settled by four measurable properties of the integration you are actually building: request volume, transaction semantics, payload size, and who owns the connection. Power Automate is the right answer when the work fits inside a published entitlement you can compute in advance. Microsoft states the entitlement precisely in its requests limits and allocations documentation: a Power Automate Premium user gets 40,000 Power Platform requests per 24 hours across all their cloud flows, a cloud flow with a Power Automate Process license gets 250,000 Power Platform requests per 24 hours, and no flow may exceed 100,000 Power Platform requests in any five-minute window regardless of license. Every action counts against that, including retries, pagination, failed actions, and an Initialize variable step. A custom integration earns its place in a narrower and quite specific set of cases: when you need transaction semantics or a compensating rollback across two systems, when sustained throughput runs past the Power Platform entitlement above and a stack of Power Automate Process licenses is no longer the cheaper answer, when a single message exceeds the Power Automate 100 MB message limit (limits of automated, scheduled, and instant flows), when a synchronous caller needs a response and the Power Automate outbound request timeout of 120 seconds is not enough, or when the source is an on-premises SQL Server and you need capabilities the Power Automate connector does not carry through a gateway. If none of those five describe your integration, the thing you are calling a platform limit is usually a design that has not been measured yet, and the custom build will reproduce it at a higher cost of ownership.

If the tool itself is still open and Power Automate is one candidate among several, start with choosing the right business automation tool for a regulated enterprise, then come back here once the shortlist is down to Power Automate versus a custom build.

This page is the decision and only the decision. How Power Automate flows are built, governed, and supported once that decision is made is covered on our Power Automate development services page, and the licensing arithmetic between Power Automate and Azure Logic Apps is covered on Power Automate vs Azure Logic Apps licensing. Neither is restated here.

The number that decides most of these, and where to read your own

Power Platform request volume is the single most common reason a Power Automate integration fails in year two after succeeding in the pilot, and it is the easiest of the four properties to measure before you commit.

Microsoft’s requests limits and allocations documentation gives the daily allocation by license. A Power Automate Premium user can make 40,000 Power Platform requests across all of their cloud flows in a tenant within a 24-hour period, and Microsoft notes that this “limit includes requests the platform makes to non-Microsoft connectors.” A cloud flow with a Power Automate Process license can make 250,000 Power Platform requests across all users of the flow in 24 hours. A user on a Microsoft 365 seeded entitlement gets 6,000 Power Platform requests per 24 hours. The Power Platform 24-hour window is a sliding one, not a calendar day: “anytime a cloud flow runs, the system looks at the requests in the past 24 hours to determine if the user is at their limit.”

Two properties of that allocation change the architecture rather than the budget. First, Power Platform capacity cannot be pooled: Microsoft’s requests limits documentation states the system “tracks this capacity based on consumption at an individual user or flow level and it can’t be pooled at any other level like environment or tenant levels.” Second, requests do not carry forward. “All Microsoft Power Platform requests exist for a 24-hour period. If you don’t consume them, they don’t roll over to the next day and they don’t accumulate within a month.” A workload with a month-end spike therefore has to be sized against the spike day, not the average.

No license lifts the ceiling that sits above the daily figure: Microsoft’s requests limits and allocations page states that “The five-minute limit is 100,000 requests and it’s independent of a user’s license,” and gives the worked example: Power Automate cloud flows with a Process license “can make 250,000 requests in 24 hours but they can’t make more than 100,000 requests within five minutes.” Any burst-shaped integration, which is most ERP and CRM synchronization, meets that ceiling before it meets the daily one.

You do not have to estimate any of this. Microsoft publishes the report on the requests limits and allocations page and the arithmetic on its Types of Power Automate licenses page. Microsoft’s arithmetic, per its Types of Power Automate licenses page (updated 20 July 2026): to have enough capacity, estimate daily usage as the number of actions per run multiplied by the number of runs per day, then purchase enough Process licenses to cover that volume. The report is in the Power Platform admin center: sign in, select Licensing on the navigation pane, select Capacity add-ons, scroll to the Add-ons section on the Summary tab, select Download reports, then New, choose Microsoft Power Platform requests, and pick the scope: Licensed User, Non-licensed User, or Per Flow Licensed Flows. It downloads as an Excel CSV with a per-flow daily action count. Microsoft flags two live limitations in that preview report, and both matter if you are about to make a decision on it: the reports are “currently limited to Power Automate API requests” with Dataverse, Copilot Studio and Power Apps requests excluded, and the Licensed user report “doesn’t show correct entitlements for users licensed via the Power Apps per app license,” showing zero where the figure should be 6,000.

One caveat that a comparison table will not tell you and that a vendor pitch will not volunteer. Microsoft’s limits of automated, scheduled, and instant flows reference publishes a transition-period limits table by performance profile: 10,000 Power Platform requests per 24 hours on Low, 200,000 on Medium, 500,000 on High, and 10,000,000 on Unlimited Extended, all higher than the limits that apply once the transition ends. Microsoft’s requests limits and allocations page is explicit about how to read that: “Once transition period ends, the official limits are applicable. Build your cloud flows based on official limits.” An integration designed against transition limits is an integration designed against a number that is scheduled to be withdrawn, and the withdrawal comes with six months of notice after the admin center reports reach general availability, not six months after you notice.

What counts as a request, because this is where the estimate usually goes wrong

Teams size the flow by the number of connector calls. Microsoft counts far more than that. For Power Automate, its requests limits and allocations page defines requests as “All API requests to connectors, process advisor analysis, HTTP actions, and built-in actions from initializing variables to a simple compose action. Both successful and failed actions count toward these limits. Retries and requests from pagination also count as action executions.”

Read what that does to a retry-heavy integration. A flow that calls a flaky endpoint and relies on the default retry policy is not consuming one request per call. On the Power Automate Medium and High performance profiles the default policy “sends up to 12 retries at exponentially increasing intervals,” so a sustained outage can multiply the consumption of every failing action by thirteen while producing no business result at all. The failure mode is not that the flow breaks. It is that the flow burns the Power Platform entitlement that the healthy integrations in the same tenant were depending on, and Microsoft’s own remedy in its limits of automated, scheduled, and instant flows reference for a consistently throttled Power Automate flow is a turn-off: “A cloud flow that is consistently throttled is turned off” after 14 days.

The definition ceilings that decide the architecture, not the budget

These are the limits on a single Power Automate flow definition, every one of them published in Microsoft’s limits of automated, scheduled, and instant flows reference, and unlike the request budget you cannot buy past them.

  • 500 actions per Power Automate workflow (Microsoft Learn). Microsoft adds a warning that the practical ceiling is lower: “Flows with a large number of actions might encounter performance issues while you edit them, even if they have fewer than 500.”
  • Nesting depth of 8 in a Power Automate flow. Deeper logic requires child flows.
  • 250 variables per Power Automate workflow, and 8,192 characters per expression (Microsoft Learn).
  • Apply to each in Power Automate processes 100,000 array items on the Medium and High profiles, 5,000 on Low. Its concurrency defaults to 1 and can be raised to 50 (Microsoft Learn).
  • Split on in Power Automate debatches 100,000 items, but “when concurrency is turned on, the Split on limit is reduced to 100 items” (Microsoft Learn).
  • 600 Power Automate flows owned by a single user outside solutions (Microsoft Learn).
  • Message size 100 MB in Power Automate, or 1 GB for actions that support chunking, and Microsoft is specific that “When you send files through a connector, the overall size of the payload and not just the file needs to be under 100 MB” (Microsoft Learn).

The Power Automate apply-to-each concurrency default of 1 is worth pausing on, because it is the most common cause of a Power Automate integration that “works but is too slow” (Microsoft Learn). A loop over tens of thousands of records at a default concurrency of one is a serial integration. Raising it to 50 is a two-click change that then interacts with the connector throttling limits below, which is exactly the kind of dependency a comparison table cannot carry and an architecture review can.

Duration, retention, and the flows that turn themselves off

Power Automate applies lifecycle limits that a custom integration does not have, and they surface as outages months after go-live.

Behavior Power Automate cloud flow Azure Logic Apps Standard workflow
Maximum run duration 30 days for a Power Automate cloud flow, and “After 30 days, any pending steps time out” 90 days for a stateful Logic Apps workflow, 5 minutes for a stateless Logic Apps workflow
Run history retention 30 days in Power Automate, calculated from the run’s start time 90 days by default in Logic Apps
Continuously failing Power Automate turns the flow off after 14 days Not applied in Logic Apps
No trigger activity Power Automate turns the flow off after 90 days, except for flows owned by premium-licensed users or holding a Power Automate Process or per-flow license Not applied in Logic Apps
Consistently throttled Power Automate turns the flow off after 14 days Not applied in Logic Apps
Outbound synchronous request timeout 120 seconds in Power Automate 225 seconds by default in Logic Apps, configurable
Actions per workflow 500 in Power Automate 500 in Logic Apps Standard
Message size 100 MB in Power Automate, 1 GB with chunking 100 MB in Logic Apps, 1 GB per action with chunking, 52 MB default chunk size

Two rows in that table cut against the received wisdom. Logic Apps does not lift the 500-action ceiling, so a plan to rebuild a flow in Logic Apps to get past the action limit is built on a limit that does not move. And the 30-day approval that times out is not a bug report; it is the documented behavior of a Power Automate flow with a pending step, which is why an approval chain with a human in it belongs in a design that assumes the human will be on leave.

One more, and it is the quietest failure in the set. Microsoft’s limits of automated, scheduled, and instant flows reference states that “A cloud flow uses the plan of its owner. If a cloud flow is shared with multiple people, then generally the owner is the flow’s creator… If the original owner leaves the organization, the flow reverts to the Low performance profile.” The Power Automate Low profile is 6,000 Power Platform requests per 24 hours and a 5,000-item apply-to-each ceiling. A production integration can therefore lose most of its Power Platform request entitlement because of an HR event, with no change to the flow. This is the single strongest argument for a Power Automate Process license on any flow that matters, because a Process license is allocated to the automation rather than to a person. The license mechanics behind that trade are covered on our Power Automate Premium vs Process page, which also answers what happens to a flow when its owner leaves.

Failure behavior is the real differentiator, and it is not close

Everything above is a ceiling. This section is about what happens when something goes wrong halfway through, and it is where the honest case for a custom build is strongest.

Power Automate’s error handling is a retry policy, not a transaction. Microsoft documents the Power Automate defaults in its limits of automated, scheduled, and instant flows reference: on the Low profile the policy “sends up to two retries at exponentially increasing intervals, which scale by 5 minutes up to an interval of approximately 10 minutes for the last retry”; on Medium and High it “sends up to 12 retries at exponentially increasing intervals, which scale by seven (7) seconds up to an interval of approximately 1 hour for the last retry.” Power Automate lets you configure up to 90 retry attempts, a maximum delay of one day and a minimum delay of five seconds.

What no retry policy gives you is atomicity. If a flow writes to system A, succeeds, then fails writing to system B, the write to A stands. There is no built-in compensating action and no two-phase commit. You can write the compensation yourself inside the flow, and teams do, but at that point you are building distributed transaction logic in the Power Automate designer with its 500-action ceiling and 8-level nesting limit, which is a worse place to build it than a codebase. If your integration has a correctness requirement that spans two systems of record, that requirement is the decision. Everything else on this page is secondary to it. This is also why silent partial failure is the characteristic Power Automate incident rather than the loud kind, a pattern we cover separately in when Power Automate flows fail silently.

Throughput of content, as opposed to requests, carries its own ceiling that most designs never look at: Power Automate content throughput per 24 hours is 200 MB on Low, 2 GB on Medium and 10 GB on High, measured as data read from or written to the flow’s run history. A high-volume document or payload integration can hold a perfectly healthy request count and still be capped on bytes.

The connector settles more of this than the platform does

Microsoft’s own tip on the limits page is the sentence to take into the architecture review: “Individual connectors have their own limits, which you often reach before the limits mentioned previously.” The SQL Server connector is the clearest worked example, and it is the connector at the center of most build-versus-configure arguments.

Start with the licensing line, because it changes the price of the option. The SQL Server connector is published as Premium for Power Automate, Power Apps and Copilot Studio, and Standard for Azure Logic Apps. The Power Automate Free license, in Microsoft’s words, has “Connector usage… limited to standard connectors only.” So an organization that believes it already owns this integration through its Microsoft 365 entitlement does not, the moment a database is in scope.

Then the operational limits, all published on Microsoft’s SQL Server connector reference:

  • Throttling. In a shared Power Platform environment, native operations (stored procedures and SQL queries) are limited to 500 API calls per connection per 10 seconds with 200 concurrent calls; CRUD operations are limited to 100 API calls per connection per 10 seconds with 125 concurrent calls (Microsoft Learn).
  • A hard action timeout. “If the execution time exceeds 110 seconds for a SQL query or stored procedure, actions will time out” (Microsoft Learn). That is a shorter fuse than the Power Automate flow’s own 120-second outbound limit, and it is the number that kills batch-shaped stored procedures.
  • On-premises payload ceilings. “The request size limit is 2 MB through on-premises SQL Server” and “The response size limit is 8 MB through on-premises SQL Server” (Microsoft Learn). Not the Power Automate 100 MB. Two and eight.
  • A capability that is simply absent through a gateway. Execute a SQL query (V2) is “Not supported for on-premises SQL Server or connections with gateway” (Microsoft Learn). If your design assumed ad-hoc queries against an on-premises database, the design does not exist.
  • Stored procedure degradation through a gateway. “Output values for OUTPUT parameters aren’t returned,” “Return value isn’t available,” “Only the first result set is returned,” and “Dynamics schemas aren’t supported for result sets” (Microsoft Learn).
  • A silent breaker. “Insert and update to a table won’t work if you defined a SQL server-side trigger on the table” (Microsoft Learn). Most mature enterprise databases have server-side triggers.
  • A discovery ceiling. “Power Platform and Logic Apps navigator views are limited to a list size of 10,000 tables” (Microsoft Learn).

Any one of the last four turns a Power Automate design into a custom build, and none of them appear in a capability comparison. This is the reason we open an evaluation by inventorying the connectors and the authentication path rather than by inventorying the requirements.

The governance surface, which is where an approved design gets blocked

Power Automate is governed centrally in a way a custom integration is not, and that cuts both ways. Data policies in the Power Platform admin center classify every connector, and Microsoft describes the enforcement path plainly: when a policy changes, the platform evaluates every app, flow and chatbot, and “If a violation occurs, put the app, flow, or chatbot in to a suspended or quarantine state so that it can’t operate,” then scans connections and disables any whose connector is blocked. Power Platform enforcement is not instant: “For the most extreme cases, the latency for full enforcement is 24 hours. In most cases, it’s within an hour.”

For a regulated buyer this is the strongest argument in Power Automate’s favor, and it is rarely made. A custom integration running in a subscription is governed by whatever your team wrote and whatever your pipeline enforces. A Power Automate integration inherits a tenant-wide connector control surface that an auditor can be shown in one screen. i3solutions governs client Power Platform tenants with the Center of Excellence Starter Kit, tenant-level and environment-level DLP policies, and managed environment controls. i3solutions runs client Power Platform work on a multi-tenant Center of Excellence model with separate Dev, Test, UAT, and Production environments promoted through managed solutions.

The corresponding risk is that the same control surface can suspend an integration you already put into production, on a policy change made by someone who has never seen your flow. That belongs in the design review, not in the incident review.

What each option actually costs to own

Microsoft’s published Power Automate list prices are the starting point, not the answer. Power Automate Premium is listed at $15.00 per user per month, paid yearly. Power Automate Process is listed at $150.00 per bot per month, paid yearly, and Power Automate Hosted Process at $215.00 per bot per month, paid yearly. A Power Automate Process license, per Microsoft’s types of Power Automate licenses documentation, is allocated to a cloud flow rather than a user, entitles that flow to up to 250,000 actions per day, “allows use of premium and custom connectors regardless of the owning or triggering user’s license,” and requires the flow to be in a solution (types of Power Automate licenses). Up to 10 Power Automate Process licenses can be stacked on one flow, each adding 250,000 actions per day, or one Process license can be shared across up to 25 flows through a flow group with no stacking available.

That stacking rule is the crossover calculation nobody runs. At the list price above, ten stacked Power Automate Process licenses give one flow 2,500,000 actions per day for $1,500 per month, which is a defensible number for an order-to-cash or claims-adjudication path that stops the business when it stops, and a poor one for an overnight batch job nobody watches. The five-minute Power Platform ceiling of 100,000 requests still applies to all of it.

On the custom side, the properties that matter are the ones Power Automate cannot offer. Microsoft’s Azure Functions scale and hosting reference gives Azure Functions a default timeout of 30 minutes on the Flex Consumption, Premium and Dedicated plans with an unbounded maximum, against 5 minutes default and 10 minutes maximum on the legacy Consumption plan. There is one Azure Functions ceiling that no plan lifts, and it catches every team that builds a synchronous API: “Regardless of the function app timeout setting, 230 seconds is the maximum amount of time that an HTTP triggered function can take to respond to a request,” because of the default idle timeout of Azure Load Balancer. Azure Functions Flex Consumption scales out to 1,000 instances. Maximum request size on Azure Functions is 210 MB across the plans.

Then the cost of ownership, which is the part of this decision that gets deferred and should not be. The two figures in this paragraph are i3solutions delivery findings rather than industry research, and we state them as our own because no published study is being cited here. In i3solutions delivery experience, a typical mid-enterprise integration project costs $150K-$400K to build, with $25K-$80K in annual operational costs over a 5-year lifecycle. The low-code path is not exempt from the same discipline, and again this is our own observation: Power Platform environments without ALM discipline accumulate technical debt requiring 40-60% more maintenance effort within 18 months, making governance frameworks essential from implementation start rather than as an afterthought. i3solutions delivery includes ALM practices with Power Platform pipelines or Azure DevOps integration, environment separation strategies, and change control processes.

Power Automate and a custom integration, side by side

Requirement Power Automate Custom integration
Daily request budget 40,000 Power Platform requests per Power Automate Premium user; 250,000 per Process-licensed flow; 6,000 on a Microsoft 365 seeded entitlement Bounded by your own compute and the target system’s limits
Burst ceiling 100,000 Power Platform requests in any 5 minutes, independent of license Bounded by Azure Functions plan scale-out; Flex Consumption to 1,000 instances
Capacity pooling Power Platform requests are not poolable across environment or tenant, and unused requests do not roll over Pooled by design
Actions in one unit of logic 500 in Power Automate, with a documented editor performance caveat below that No platform-imposed ceiling
Cross-system atomicity Not available in Power Automate; retry policy only, no compensating rollback Available if you build it, and the reason to build it
Default failure handling Up to 12 exponential retries on the Power Automate Medium and High profiles; every retry consumes the Power Platform request budget Whatever you implement, and it is your job to implement it
Max run duration 30 days in Power Automate; pending steps time out at 30 days Unbounded Azure Functions timeout on Flex Consumption, Premium and Dedicated plans
Synchronous response window 120 seconds outbound in Power Automate 230 seconds maximum for an HTTP-triggered Azure Functions request, regardless of timeout setting
Payload ceiling 100 MB in Power Automate, 1 GB with chunking; 2 MB request and 8 MB response through an on-premises SQL Server gateway 210 MB max request size on Azure Functions
Lifecycle auto-shutoff Power Automate turns a flow off after 14 days failing, 14 days throttled, or 90 days without trigger activity Not applied
Ownership risk A Power Automate flow reverts to the Low profile if the owning user leaves; a Process license removes this Owned by a subscription and a pipeline, not a person
Central governance Tenant-wide Power Platform connector data policies, with suspend and quarantine enforcement inside 24 hours Whatever your pipeline and review process enforce
Published list price $15.00 user/month Power Automate Premium; $150.00 bot/month Process; $215.00 bot/month Hosted Process, all paid yearly Azure consumption plus build and run cost; see the ownership figures above

The honest “do not do this” on both sides

Do not use Power Automate if the integration has a correctness requirement that spans two systems of record and needs a compensating rollback; if measured volume, computed as actions per run multiplied by runs per day, exceeds the Power Platform entitlement on the spike day rather than the average day and stacked Power Automate Process licenses are no longer the cheaper answer; if a single message exceeds the Power Automate 100 MB message limit, or 2 MB inbound and 8 MB outbound where an on-premises SQL Server gateway is in the path; if a caller needs a synchronous answer in more than the Power Automate outbound limit of 120 seconds; or if the source system requires ad-hoc queries, OUTPUT parameters, multiple result sets or writes to a table carrying a server-side trigger, all of which Microsoft’s SQL Server connector reference documents as unsupported or degraded.

Do not build custom if the only stated reason is a platform limit nobody has measured against the admin center report; if you have no ALM, no environment separation and no change control, because a custom integration in that state is the expensive version of the same problem; if the work is a single system-to-system hop already covered by a certified connector, where a custom build buys you a maintenance obligation and no capability; or if the driver is a preference for code rather than a property of the integration. The most expensive outcome we see is not the wrong platform. It is a custom integration built to escape a limit that a Power Automate Process license would have lifted for $150 a month.

How to settle this with evidence rather than opinion

The sequence is short and every step produces an artifact you can put in front of an architecture review board.

  1. Instrument before you argue. Download the Power Platform requests report from the admin center for all three scopes and read the per-flow daily action count. Note the two documented preview gaps above so the number is not over-read.
  2. Compute the spike day. Actions per run multiplied by runs per day, taken at month-end or the busiest known cycle, then checked against both the 24-hour Power Platform entitlement and the 100,000-requests-per-five-minutes ceiling.
  3. Inventory the connectors and the authentication path. Every premium connector, every custom connector, every gateway hop, and the license each one requires. This is where most designs actually fail.
  4. State the correctness requirement in one sentence. If that sentence contains “must not leave system A and system B disagreeing,” you have a custom build and the rest of the analysis is confirmatory.
  5. Price both to five years, not to launch. License cost plus build cost plus the annual run cost, against the same three lines for the alternative.
  6. Write the decision down with the numbers attached. That document is the thing that survives the next reorganization, and it is the artifact your board asked for.

Enterprise workflow automation consulting engagements typically range from $75,000 to $350,000 for Phase 1 assessment and pilot delivery, depending on process complexity, integration surface area, and compliance framework requirements. The decision that precedes it is a much smaller piece of work: the steps above are two to three weeks of elapsed time against your own admin center data, and that assessment can be scoped and delivered without committing to either build.

Bring three things to that conversation and you can settle the platform question inside it: the Power Platform requests report for the flows in scope, the connector and gateway inventory for the systems you are joining, and the one sentence that states your correctness requirement. An architect can tell you from those three whether you are looking at an entitlement you can buy, a design that has not been measured, or a genuine boundary that needs code, and which of the three costs the least to act on. i3solutions routes a senior U.S.-based engineer to a client call usually within one to two weeks.

Talk to a senior workflow architect

What we have actually built on both sides of this line

i3solutions runs a governed Power Platform for a federal defense agency supporting roughly 10,000 personnel across about 180 locations, which works because it is governed, not despite it. i3solutions unified identity and automated provisioning across systems for 125,000 users by treating the interfaces as owned, governed contracts. i3solutions has implemented governance frameworks for organizations managing 200+ integrations across Microsoft ecosystems.

The capability behind the custom side is specific rather than general. i3solutions implements monitoring and observability for Microsoft integration landscapes: Azure Monitor, Application Insights, intelligent alerting, and standardized runbooks that reduce mean time to resolution from hours to minutes. i3solutions implements Power Platform licensing across Power Apps per-app and per-user plans, Power Automate per-flow and per-user plans, and the Microsoft 365 default entitlements where app complexity is low. i3solutions delivery pods use standardized environments, connection references, and solution packaging from day one.

One i3solutions delivery finding shapes how we sequence the work. By year-end, i3solutions client teams typically manage 15 to 25 production flows independently while maintaining the architectural patterns i3 established.

i3solutions has been a Microsoft partner since 1997. i3solutions is a Microsoft Solutions Partner. i3solutions has completed more than 600 Microsoft platform implementations. Delivery teams consist of senior-level Microsoft architects and developers based in the United States.

What we are not claiming

Every third-party figure on this page is a quotation from Microsoft’s published documentation or from the Power Automate pricing page, cited in full at the end, and all of it was read on 14 September 2026. Microsoft revises these Power Platform limits: the request allocations were “substantially increased in late 2021,” the transition period limits are explicitly temporary, and the admin center reporting is in preview. Check the current version before you commit a design.

We have not priced a non-Microsoft integration platform on this page and are not making a claim about one. Where the honest answer is a dedicated integration product rather than either option compared here, that is a correct outcome and we will say so. i3solutions does run comparative platform-selection evaluations rather than only implementing the Microsoft option, including Power Automate against Workato and Power Automate against dedicated RPA platforms.

Frequently asked questions

How many requests does a Power Automate flow actually get per day?

Between 6,000 and 250,000 Power Platform requests per 24 hours, set by the license attached to the user or the flow rather than by the flow itself. Microsoft’s requests limits and allocations page publishes 40,000 Power Platform requests per 24 hours for a Power Automate Premium user across all their cloud flows, 250,000 per 24 hours for a cloud flow carrying a Power Automate Process license or the legacy per-flow plan, and 6,000 for a Microsoft 365 seeded entitlement. The Power Platform window is a sliding 24 hours rather than a calendar day, capacity cannot be pooled at environment or tenant level, and unused requests do not roll over. Above all of those sits a five-minute Power Platform limit of 100,000 requests that no license lifts. Note that every tenant is currently in a transition period with more generous enforced limits, and Microsoft’s guidance is to build against the official limits rather than the transition ones.

What counts as a request or an action in Power Automate?

More than most estimates assume. Microsoft’s requests limits and allocations page counts “All API requests to connectors, process advisor analysis, HTTP actions, and built-in actions from initializing variables to a simple compose action. Both successful and failed actions count toward these limits. Retries and requests from pagination also count as action executions.” The practical consequence is that a flow calling an unreliable endpoint consumes far more than one Power Platform request per call, because the default retry policy on the Power Automate Medium and High performance profiles sends up to 12 retries at exponentially increasing intervals. A Power Automate flow that is consistently throttled is turned off after 14 days.

When is a custom integration genuinely the right answer?

Five cases, and they are properties of the integration rather than preferences about tooling. First, when correctness must hold across two systems of record: Power Automate offers a retry policy, not a transaction, and there is no built-in compensating rollback. Second, when measured volume on the spike day exceeds the Power Platform entitlement and stacked Power Automate Process licenses stop being the cheaper answer, noting that up to 10 can be stacked on one flow at 250,000 actions each. Third, when a single message exceeds the Power Automate 100 MB message limit, or 2 MB inbound and 8 MB outbound where an on-premises SQL Server gateway is in the path. Fourth, when a caller needs a synchronous answer beyond the Power Automate 120-second outbound request timeout. Fifth, when the source system needs capabilities the Power Automate connector does not carry, such as ad-hoc queries against on-premises SQL Server, OUTPUT parameter values through a gateway, or writes to a table with a server-side trigger.

Does Power Automate work with our on-premises SQL Server?

It connects through the on-premises data gateway, and it does so with material restrictions that belong in the design rather than in the incident report. Microsoft’s SQL Server connector reference states that the request size limit is 2 MB and the response size limit is 8 MB through on-premises SQL Server, that Execute a SQL query (V2) is “Not supported for on-premises SQL Server or connections with gateway,” and that when invoking a stored procedure through a gateway, OUTPUT parameter values are not returned, the return value is not available, only the first result set is returned, and dynamic schemas are not supported. Separately, insert and update to a table will not work through the Power Automate SQL Server connector if a server-side trigger is defined on that table, and any query or stored procedure running longer than 110 seconds times out. The connector is Premium for Power Automate, so a Microsoft 365 seeded entitlement does not cover it.

Will rebuilding the flow in Azure Logic Apps get us past the limits?

Some of them, and not the one people usually name. Logic Apps Standard carries the same 500-action ceiling per workflow and the same 100 MB message size, so a design blocked by action count is not unblocked by the move. What does change is duration and timeout: a stateful Logic Apps Standard workflow runs up to 90 days against Power Automate’s 30, run history retention defaults to 90 days against 30, and the outbound request timeout defaults to 225 seconds against Power Automate’s 120. Note that a stateless Logic Apps Standard workflow defaults to a 5-minute run duration, which is a different tradeoff again. The licensing model also changes: the SQL Server connector is published as Standard for Logic Apps and Premium for Power Automate.

Related

Sources