Power Automate vs Azure Logic Apps

What it does

Two designer-first workflow products sitting on the same lineage — Power Automate grew out of the Azure Logic Apps engine and they still share the designer shape, the expression language and most of the connector catalogue. What differs is who buys it, who owns it, how it deploys and what happens when it needs to scale.

Key facts

The connector catalogues overlap heavily but aren't identical. Logic Apps advertises 1,400+ Azure-hosted connectors plus built-in operations that run on the Logic Apps runtime; Power Automate has its own set, including a lot of Microsoft 365 surface that Logic Apps has no reason to carry.
Access control works differently. Logic Apps uses Azure RBAC at resource level, so if the author leaves the organisation you don't lose the workflow. Power Automate access is tied to users, connections and environment security roles — a departing owner is a real operational event.
Logic Apps Standard runs on dedicated compute: single-tenant Logic Apps, App Service Environment v3, or your own infrastructure via hybrid deployment. Power Automate runs on shared Microsoft-managed capacity and you get no hosting choices.
Logic Apps Standard supports virtual network integration, private endpoints and managed identity authentication. Power Automate reaches private networks through the on-premises data gateway and authenticates with stored connections.
Standard logic apps can be developed, debugged and run locally in Visual Studio Code with the Azure Logic Apps extension, then deployed as ARM resources through normal CI/CD. Power Automate ALM runs through Dataverse solutions, Power Platform pipelines and Git integration.
Logic Apps Standard workflows can host inline .NET code, C# scripts and PowerShell scripts. Power Automate can't — you go out to a Function or a custom connector.
Desktop flows and RPA, approvals, process mining and business process flows exist only in Power Automate. B2B/EDI through the Enterprise Integration Pack exists only in Logic Apps.
Monitoring diverges completely: Power Automate gives you run history in the maker portal plus optional Application Insights; Logic Apps gives you Azure Monitor logs, Application Insights, health checks and Defender for Cloud.
A cloud flow can call a logic app workflow and vice versa. Mixed estates are normal and supported.

When to use / skip

The honest rule: if the workflow serves people, use Power Automate. If it serves systems, use Logic Apps. An approval that lands in someone's Teams chat, a SharePoint document routine, anything a business user will eventually want to tweak — Power Automate, every time. A nightly integration moving fifty thousand records between an ERP and a warehouse, inside a virtual network, owned by a platform team with a release pipeline — Logic Apps, and don't let anyone talk you into building it in Power Automate because "we already have the licences".

The failure mode you'll actually meet is the second one. A department builds an integration in Power Automate because it was quick, it grows to production-critical, and now nobody can deploy it safely, nobody can see it in Azure Monitor, and it's owned by someone's personal connection. Migrating it later costs more than building it right would have. Where the volume, network isolation or ownership model points at Azure, say so at design time rather than after the first incident.

Configuration decisions

Who owns and operates this in eighteen months — a business team or a platform team? That single answer settles the product more reliably than any feature comparison.
Does it need to run inside a virtual network, behind private endpoints, or authenticate with managed identity? If yes, it's Logic Apps Standard.
What's the deployment model you're prepared to support — solutions and pipelines, or ARM/Bicep through Azure DevOps?
Where does monitoring have to land? If the client's operations team lives in Azure Monitor, don't hand them run history in a maker portal.
Is there any human interaction, approval or mobile surface in the process? That pulls it back to Power Automate regardless of volume.

Gotchas

"Same engine" gets read as "same product". People assume a flow can be lifted into Logic Apps unchanged. Some patterns port cleanly, connectors and expressions largely do, but triggers, connection references and anything Power Platform-specific do not.
Power Automate connections belong to individuals. Service accounts are the usual workaround and clients dislike paying for them, but the alternative is an integration that dies when someone changes role.
Logic Apps Consumption bills per action executed. A chatty loop that felt free under a per-user Power Automate licence becomes a visible line item in Azure. Model it before you migrate anything high-volume.
The connector with the same name may behave differently between the two platforms, particularly around triggers and pagination. Test, don't assume.
Power Automate has no equivalent to Logic Apps' resource-level RBAC. Co-ownership and service principals get you part of the way; they don't get you parity.

Consultant notes

Frame it as a portfolio decision, not a contest. Most enterprises should be running both, with a documented rule for which side of the line new work falls on. Write that rule down in the first architecture workshop.
Watch for the licensing argument being used as an architecture argument. "It's included" is a real consideration and a bad reason to put a system-to-system integration on shared capacity.
If a client already has an Azure landing zone and a platform team, Logic Apps Standard is a much easier operational sell than most Power Platform people expect. Take the win.
The migration path exists and Microsoft documents it, but budget it properly. It's a rebuild with a head start, not an export/import.

Revisit whenever Logic Apps Standard picks up another Power Platform-shaped feature — the boundary has moved twice already