Logic Apps vs Power Automate: which to use, with limits and licensing

Logic Apps vs Power Automate: the same designer, different owners, limits, licensing and lifecycle. A decision table, the hard limits side by side, and when to use both together.

Azure + Power PlatformChoose a tool5 min read

Checked against Microsoft Learn 11 Oct 2026 · 7 sourcesPosted by the Maker DeskHow we write guides

Logic Apps vs Power Automate is less a choice of tool than a choice of owner. Both are designer-first, with similar designers and many of the same connectors, and a flow in one can call a workflow in the other. What differs is who builds and owns the automation, how it's licensed and billed, how far it can scale, and how it moves from test to production.

Choose Power Automate when

People start or take part in it: a button, a Power Apps app, an approval, a Copilot Studio agent, or a Teams or Outlook event.
It works inside Microsoft 365 and Dataverse, and belongs next to an app in the same solution.
Makers maintain it without an Azure subscription or developer tools.
Your Power Platform data policies should govern it, with the rest of your environment's apps and flows.
Licences you already have cover it: standard connectors come with many Microsoft 365 plans; premium connectors need Power Automate Premium for each user, or a Process licence for the flow.

Choose Logic Apps when

IT or developers own it, and it shouldn't stop working when one person leaves. Access is granted on the Azure resource, so the workflow doesn't belong to its creator. (A Power Automate flow belongs to people; see what to do when a flow's owner leaves.)
Volume is high or performance must be predictable. The Standard plan runs on dedicated compute that scales out.
It needs private networking: Standard workflows can run inside a virtual network and reach resources through private endpoints.
It talks to Azure resources with a managed identity instead of a stored credential.
It must live in Git and deploy through pipelines as code, with Bicep or ARM templates.
A run can take longer than 30 days, or it's B2B and EDI integration.

The limits side by side

Limit	Power Automate cloud flows	Logic Apps Consumption	Logic Apps Standard
Longest run	30 days; pending steps, such as approvals, then time out	90 days by default; you can set 7 to 365	90 days by default for stateful workflows, configurable; stateless ones run for minutes
Run history kept	28 to 30 days	Same setting as the run length	90 days by default, configurable
Daily capacity	Power Platform requests per 24 hours, by licence (below)	No daily allowance: you pay for each action run	Whatever your hosting plan's instances can run
Waiting for one HTTP call	2 minutes, unless the call is asynchronous	2 minutes per action	2 minutes per action
Where it runs	Shared Power Platform capacity	Shared, multitenant Azure	Dedicated: single-tenant, an App Service Environment, or your own infrastructure

Power Automate's daily request limits count every trigger and action run, including each pass through a loop, retries and failed actions. Microsoft's official limits are 40,000 requests per 24 hours for a user with Power Automate Premium (or Power Apps Premium), 6,000 with Microsoft 365, and 250,000 for a flow with a Process licence. Higher "transition period" limits apply until Microsoft finishes rolling out usage reports, so plan for the official ones. A flow that stays over its limit is slowed and, after 14 days, turned off.

Each connector also has its own throttling limit, which you often reach first. SharePoint, for example, allows 600 calls a minute per connection.

Licensing and cost, in models

Prices change, so this compares how each is charged rather than what it costs:

Power Automate is licensed per user (the user's flows run within that user's allowance) or per flow (a Process licence gives one flow, or a group of up to 25 flows, its own capacity).
Logic Apps Consumption is billed to an Azure subscription for each trigger and action that runs, which suits spiky or low volume.
Logic Apps Standard is billed for the hosting plan you choose, whether or not the workflows are busy, which suits steady, high volume.

Lifecycle and monitoring

	Power Automate	Logic Apps
Moving between environments	Solutions, with pipelines in Power Platform, Azure DevOps or GitHub Actions	ARM templates or Bicep through any CI/CD tool; Standard projects in Visual Studio Code and Git
Who can edit	Owners and co-owners of the flow	Anyone with an Azure role on the resource
Monitoring	Run history and analytics in the maker portal; export to Application Insights	Azure Monitor, Log Analytics and Application Insights alerts
Governance	Power Platform data policies and environments	Azure role-based access control and Azure Policy

Use both together

You don't have to pick one for a whole process. A common pattern lets people start it in Power Automate, from an app, an approval or a Teams message, and hands the heavy or sensitive part to a Logic Apps workflow: bulk processing, calls into a private network, or anything that needs a managed identity. The flow calls the workflow over HTTP and waits for its answer, or leaves it running and gets notified when it's done. Each side stays with the team that owns it.

Sources

Choose the right integration and automation services in Azure, Microsoft Learn
Power Automate migration to Azure Logic Apps (Standard), Microsoft Learn (capability comparison)
Limits of automated, scheduled, and instant flows, Microsoft Learn
Requests limits and allocations, Microsoft Learn
Power Automate licensing FAQ, Microsoft Learn
Limits and configuration reference for Azure Logic Apps, Microsoft Learn
Troubleshoot and diagnose workflow failures in Azure Logic Apps, Microsoft Learn (the 2-minute action timeout)

Was this helpful?

Comments

No comments yet. Share what worked for you.