The Problem Nobody Wants to Admit
Microsoft gives you two products that look nearly identical on a slide deck: Azure Logic Apps and Power Automate. Both are low-code/no-code workflow automation tools. Both have connectors for Office 365, SharePoint, SQL, and hundreds of other services. Both sit under the same Azure umbrella.
So your team starts building. A citizen developer spins up a Power Automate flow. A DevOps engineer builds the same integration in Logic Apps Standard. Six months later, you have a schizophrenic integration layer nobody fully understands, owned by nobody, and crashing in production at 2am on a Saturday.
This article is the decision framework you needed before you started building. We’ll cover the real architectural differences, the hidden pricing traps, and the production-readiness gaps that the official documentation buries in footnotes.
Official GitHub for Logic Apps samples and community connectors: https://github.com/Azure/logicapps
What Logic Apps Actually Is (Not the Marketing Version)
Logic Apps is a managed iPaaS (Integration Platform as a Service) running on Azure. Under the hood it’s a workflow runtime — in 2026 that means the Azure Functions extensibility model, specifically the Durable Functions engine for stateful orchestration.
There are two flavors and they are genuinely different products:
Consumption (multi-tenant): You get a designer, you pay per action execution, the runtime is fully managed and shared. Microsoft handles everything. You lose control of almost everything too.
Standard (single-tenant): You get a dedicated App Service plan (or Container Apps) running the Logic Apps runtime. You can run locally with VS Code, deploy via CI/CD with ZIP deploy or container images, and you get full access to host.json and the workflow runtime. Stateful and stateless workflows live side by side.
The Consumption tier never escaped its "enterprise glue" reputation — it’s genuinely fine for connecting SaaS tools, but it has hard limits on payload size (100MB), run duration (90 days max for stateful), and zero local development story. You build in the browser, you test in the browser, you cry in the browser.
Standard is the product that grew up. It has a local development loop, proper DevOps support, and it runs in your own compute.
Power Automate: Honest Positioning
Power Automate (still occasionally called Flow internally at Microsoft, despite the rebrand years ago) is positioned as a citizen developer tool. That’s not an insult — it’s a specific use case description.
It lives in the M365 licensing ecosystem. If your users have Microsoft 365, they have Power Automate. It’s designed so a business analyst can automate their own Outlook → SharePoint → Teams notification pipeline without filing an IT ticket.
The connectors are the same pool. Many of the UI concepts are identical to Logic Apps Consumption. But the architecture underneath is completely different — Power Automate flows run in Microsoft’s shared cloud with no visibility, no custom runtime configuration, and licensing that is attached to user identities rather than Azure subscriptions.
This last point matters more than people realize. A Power Automate flow that automates a business process is owned by whoever created it. When that person leaves the company and their license gets revoked, the flow dies. Silently. At 2am on a Saturday.
The Real Comparison Matrix
Let’s cut through the feature tables that Microsoft publishes and focus on what actually matters in production.
Developer Experience
Logic Apps Standard wins completely. You can:
# Install the Logic Apps extension locally
npm install -g @microsoft/logic-apps-designer
# Or use the VS Code extension (Azure Logic Apps Standard)
# and run the full runtime locally with Azurite for storage emulation
func host start
You get breakpoints, local triggers, hot reload on workflow JSON edits. The workflow definition is just a JSON file — workflow.json — which means you can version it, diff it, review it in PRs.
Power Automate has no local development. You have a browser-based designer, a web-based test button, and a run history screen. That’s it. There’s no CLI, no offline execution, no way to export a flow and run it in a staging environment.
CI/CD and Deployment
Logic Apps Standard supports proper pipeline deployment. Here’s a minimal Azure DevOps YAML that deploys a Standard Logic App via ZIP:
# azure-pipelines.yml
trigger:
- main
pool:
vmImage: ubuntu-latest
variables:
LOGIC_APP_NAME: 'my-integration-app'
RESOURCE_GROUP: 'prod-integrations-rg'
stages:
- stage: Build
jobs:
- job: Package
steps:
- task: ArchiveFiles@2
inputs:
rootFolderOrFile: '$(System.DefaultWorkingDirectory)/workflows'
includeRootFolder: false
archiveType: zip
archiveFile: '$(Build.ArtifactStagingDirectory)/logicapp.zip'
- task: PublishBuildArtifacts@1
inputs:
pathToPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: drop
- stage: Deploy
dependsOn: Build
jobs:
- deployment: DeployLogicApp
environment: production
strategy:
runOnce:
deploy:
steps:
- task: AzureFunctionApp@2
inputs:
azureSubscription: '$(SERVICE_CONNECTION)'
appType: workflowapp
appName: '$(LOGIC_APP_NAME)'
package: '$(Pipeline.Workspace)/drop/logicapp.zip'
deploymentMethod: zipDeploy
Power Automate has an "export as ZIP" feature and a pac flow CLI via the Power Platform CLI. Technically you can script deployments. In practice, the tooling is immature, environment variables are called "environment variables" in one place and "connection references" in another, and connection authorization often breaks on import because it’s tied to user identity. It works for basic flows but falls apart at scale.
Pricing Model
This is where teams get burned.
Logic Apps Consumption: ~$0.000025 per action. Sounds cheap. A workflow with 20 actions that runs 50,000 times a month is $25. Fine. But the "actions" count includes every step, every condition check, every iteration of a loop. A flow processing 1,000 items with 15 steps per item runs 15,000 actions. The bill scales fast.
Logic Apps Standard: You pay for the App Service Plan or Container Apps infrastructure. Fixed cost, predictable. For anything running frequently, this is almost always cheaper at scale. Minimum cost is roughly the App Service Plan WS1 (~$150/month) but you can run unlimited workflows.
Power Automate: Licensed per user per month. Plans range from ~$15 (per-user) to the "Process" license at ~$150/month for unattended flows running under a service account. Premium connectors (Dataverse, custom HTTP endpoints) require at minimum the per-user Premium plan. If your integration needs to call an HTTPS endpoint, that’s a premium connector. Yes, really.
Gotcha: Power Automate’s "premium connector" definition changes. Microsoft has reclassified connectors from standard to premium mid-subscription cycle before. If your budget is based on "no premium connectors," audit quarterly.
Networking and Security
Logic Apps Standard can run in a private VNet. You can inject it into a subnet, disable public access, and route all outbound calls through your firewall. This is non-negotiable for many enterprise security requirements.
// In your Logic App resource definition (Bicep excerpt)
resource logicApp 'Microsoft.Web/sites@2023-01-01' = {
name: logicAppName
location: location
kind: 'workflowapp,functionapp'
properties: {
serverFarmId: appServicePlan.id
siteConfig: {
// Disable public network access
publicNetworkAccess: 'Disabled'
}
virtualNetworkSubnetId: integrationSubnet.id
}
}
Power Automate has no VNet integration option for flows themselves. You get IP ranges for allow-listing on your firewall, but the flows run on Microsoft’s shared infrastructure and you cannot prevent outbound traffic from going through the public internet. If your compliance team requires traffic to stay within your network perimeter, Power Automate is out of scope.
Logic Apps Consumption sits in the middle — there’s an ISE (Integration Service Environment) offering for VNet isolation, but ISE is expensive and Microsoft has been quietly soft-deprecating it in favor of pushing customers to Standard. Check current status before committing to ISE.
When to Use Each: The Actual Decision Tree
Use Logic Apps Standard when:
- The workflow is business-critical and needs proper change management
- You need VNet integration or private endpoints
- You have DevOps requirements (staging environments, CI/CD, PR reviews)
- The logic is complex: long-running orchestrations, batching, retry policies with custom logic
- You need to debug locally before deploying
- You’re building something that will run indefinitely and you want predictable infrastructure cost
Use Logic Apps Consumption when:
- You’re prototyping and don’t want to manage infrastructure
- The workflow is genuinely simple: "when X happens, do Y"
- Run frequency is low (a few times a day, not thousands of times)
- You need rapid deployment and the designer experience matters more than DevOps
Use Power Automate when:
- The workflow owner is a business user, not a developer
- It touches M365 data (SharePoint, Teams, OneDrive) and user context matters
- You’re automating personal or departmental workflows, not company-wide integrations
- The licensing is already covered by existing M365 subscriptions
- The flow is low-stakes and user-owned ("if I get an email from my boss, send it to Teams")
Never use Power Automate when:
- The workflow runs under a service account with no human owner
- Compliance requires audit trails you control (Power Automate logs are in Microsoft’s tenant)
- You need to call internal APIs that aren’t publicly reachable
- You’re building anything that the business will treat as infrastructure
A Concrete Logic Apps Standard Workflow Example
Here’s a real-world scenario: processing messages from an Azure Service Bus queue, enriching each message with a database lookup, and posting results to a REST API with retry logic.
The workflow.json for this would live at src/workflows/process-order/workflow.json:
{
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"triggers": {
"When_a_message_is_received_in_a_queue": {
"type": "ServiceProvider",
"inputs": {
"parameters": {
"queueName": "@appsetting('SERVICE_BUS_QUEUE_NAME')",
"isSessionsEnabled": false
},
"serviceProviderConfiguration": {
"connectionName": "serviceBus",
"operationId": "receiveQueueMessages",
"serviceProviderId": "/serviceProviders/serviceBus"
}
},
"recurrence": {
"frequency": "Second",
"interval": 10
}
}
},
"actions": {
"Parse_message_body": {
"type": "ParseJson",
"inputs": {
"content": "@base64ToString(triggerBody()?['contentData'])",
"schema": {
"type": "object",
"properties": {
"orderId": { "type": "string" },
"customerId": { "type": "string" }
}
}
},
"runAfter": {}
},
"Lookup_customer_in_SQL": {
"type": "ServiceProvider",
"inputs": {
"parameters": {
"query": "SELECT email, tier FROM customers WHERE id = @customerId",
"queryParameters": {
"customerId": "@body('Parse_message_body')?['customerId']"
}
},
"serviceProviderConfiguration": {
"connectionName": "sql",
"operationId": "executeQuery",
"serviceProviderId": "/serviceProviders/sql"
}
},
"runAfter": {
"Parse_message_body": ["Succeeded"]
}
},
"Post_to_fulfillment_API": {
"type": "Http",
"inputs": {
"method": "POST",
"uri": "@appsetting('FULFILLMENT_API_URL')",
"headers": {
"Content-Type": "application/json",
"X-Api-Key": "@appsetting('FULFILLMENT_API_KEY')"
},
"body": {
"orderId": "@body('Parse_message_body')?['orderId']",
"customerEmail": "@body('Lookup_customer_in_SQL')?['ResultSets']?['Table1']?[0]?['email']",
"customerTier": "@body('Lookup_customer_in_SQL')?['ResultSets']?['Table1']?[0]?['tier']"
},
"retryPolicy": {
"type": "exponential",
"count": 4,
"interval": "PT7S",
"minimumInterval": "PT5S",
"maximumInterval": "PT1H"
}
},
"runAfter": {
"Lookup_customer_in_SQL": ["Succeeded"]
}
}
}
},
"kind": "Stateful"
}
Note the @appsetting() references — all configuration comes from app settings, not hardcoded into the workflow. This is how you keep the same workflow.json deployable across dev, staging, and prod without modification.
Gotchas You’ll Hit in Production
The connection string trap in Standard: Logic Apps Standard uses connection configuration files (connections.json) that reference managed identity or connection strings. In local dev these are stored in local.settings.json. In production they bind to app settings. If your CI/CD pipeline deploys without setting these app settings first, the workflow runtime starts but all trigger connections fail silently. The run history shows nothing because no triggers fire. Add a health check step to your pipeline.
Power Automate connection expiry: OAuth connections in Power Automate expire. Premium connector connections typically need re-authorization every 12-18 months. If nobody notices, the flow stops. There’s no native alerting for expired connections — you have to build monitoring on top via the Power Platform admin center or accept the phone call from the business at 2am.
Logic Apps Consumption action count explosions: For each loops in Consumption Logic Apps run actions sequentially by default and each iteration counts as a full action set. A loop over 500 items with 10 actions each is 5,000 billed actions per run. You can enable parallelism (up to 50 concurrent) to reduce wall-clock time, but the action count stays the same. Design your loops before you deploy.
Stateful vs stateless in Standard: Stateless workflows are faster and cheaper (no checkpoint storage) but they have a maximum run duration of 5 minutes and no run history persistence beyond in-memory. If you’re building something that needs the run history for debugging or audit, it must be stateful. Don’t discover this after 3 months of missing run history.
The "works on my machine" designer divergence: The VS Code Logic Apps designer occasionally renders workflows differently from the Azure portal designer. The underlying JSON is the source of truth — if you see a discrepancy, trust the JSON. Never use the portal to make one-off edits to a workflow that’s managed by CI/CD, or you’ll have drift between your repo and production.
The Organizational Reality
Here’s the honest take: the problem isn’t technical. Both tools work. The problem is governance.
Power Automate creates shadow IT. Business users build flows, use personal connections, and the IT team has no visibility until something breaks or a departing employee’s flows take down a process. The Power Platform admin center helps, but only if you’ve invested in setting up DLP policies and environment governance before people start building.
Logic Apps creates the opposite problem — developers build integrations that business users can’t understand or maintain, and every change requires a deployment pipeline.
The teams that get this right do two things: they define a clear ownership boundary (M365 data and user-initiated workflows go to Power Automate; system integrations and API orchestration go to Logic Apps), and they invest in a Center of Excellence model for Power Automate governance so citizen developers operate within guardrails.
If you’re a solo DevOps engineer or a small team, just use Logic Apps Standard for everything that matters. The overhead of the toolchain pays back within the first production incident you can debug locally.
Migrating Between the Two
Microsoft has no official migration tool between Power Automate and Logic Apps. The connector actions share naming conventions and parameter shapes (they come from the same connector SDK), so the logic translates, but you’re doing it manually.
If you’re migrating a Power Automate flow to Logic Apps Standard:
- Export the flow as a
.zipfrom Power Automate and unpack it — thedefinition.jsoninside uses the same schema dialect as Logic Apps workflow definitions. - The trigger type will need to change — Power Automate recurrence triggers map to Logic Apps recurrence triggers but the polling triggers need to be re-mapped to their Logic Apps equivalents.
- Connection references in Power Automate (the named references to OAuth connections) map to app settings +
connections.jsonin Logic Apps Standard. - Test every expression — Power Automate and Logic Apps share the workflow expression language, but there are subtle behavioral differences in how null handling works with some connector outputs.
It’s a half-day job for a simple flow, a week for something complex. Factor this in when choosing Power Automate for anything you might want to promote to production-grade later.
Final Take
In 2026 the gap between Logic Apps Standard and Power Automate has widened in the developer experience dimension and narrowed in the connector coverage dimension. They cover the same functional territory but serve fundamentally different users and operational contexts.
If you’re building integrations that your organization depends on — treat them like software. Use Logic Apps Standard, put them in source control, run them through a pipeline, monitor them with Azure Monitor and alerts. The citizen developer tool is not the right foundation for business-critical automation.
Power Automate earns its place for the long tail of personal and departmental automation that would otherwise be unsupported or require IT tickets. Keep it there, govern it with DLP policies, and don’t let it creep into your critical path.
Pick your lane and enforce it. The failure mode isn’t using the wrong tool once — it’s letting both tools grow unchecked until you have a dependency map nobody can draw.