Logic Apps Standard vs Consumption

The two Logic Apps hosting models — Standard (single-tenant) vs Consumption (multi-tenant) — and how to choose between them for Dynamics 365 integrations.

Updated 2027-01-04

Azure Logic Apps is Microsoft's iPaaS-grade orchestration platform, used heavily for Dynamics 365 integrations. It ships in two distinct hosting models — Consumption (the original, multi-tenant, pay-per-execution) and Standard (newer, single-tenant, App Service-hosted). Choosing the right one matters; the trade-offs are real.

Consumption Logic Apps. The original model, in market since 2016:

  • Multi-tenant — workflows run on Microsoft's shared compute infrastructure.
  • Pay-per-execution — billed per action execution. No standing charges; pay only what runs.
  • Auto-scale — runs on Microsoft's elastic infrastructure; no capacity to manage.
  • Single workflow per Logic App resource — each Logic App is one workflow.
  • Trigger limitations — some triggers (especially long-polling) have constraints.
  • Connectors — wide library, both standard and premium.
  • Cold start — first execution after idle period has small latency.
  • Designer-friendly — Azure portal designer is rich and stable.

Strong fit for: low-to-moderate volume integrations, business-process orchestrations, simple workflows, prototypes.

Standard Logic Apps. Newer model, launched 2021:

  • Single-tenant — workflows run on dedicated Azure App Service infrastructure under your control.
  • Predictable cost — fixed App Service plan cost; workflow executions don't bill per-action.
  • Multiple workflows per Logic App resource — group related workflows into one resource.
  • VNET integration — run inside an Azure VNET for private networking to on-premise systems.
  • Local development — Visual Studio Code extension runs Logic Apps locally; full source-control friendly.
  • No cold start — App Service stays warm.
  • Stateful and stateless workflows — choose per workflow whether to persist state (durable) or run stateless (faster, no recovery).
  • More complex deployment — App Service plan to manage; deployment slots; scaling rules.

Strong fit for: high-volume integrations (cost predictability matters), enterprise integration patterns, VNET-required scenarios, source-controlled enterprise workflows.

Cost comparison.

  • Consumption — generous free tier; pay per action. At low volume, very cheap. At high volume (millions of actions per month), costs add up substantially.
  • Standard — fixed monthly cost for the App Service plan (typically a few hundred dollars per month for a small plan), regardless of execution count. Cost-effective at scale; over-priced for low-volume.

The break-even point varies by workflow complexity but is typically around hundreds of thousands of action executions per month.

Feature parity. Standard has caught up substantially but some differences remain:

  • Some triggers and connectors are Consumption-only or have different behaviour.
  • Designer feature gaps — both designers have evolved; check current docs.
  • Integration patterns — some advanced patterns (built-in messaging, durable orchestrations) work differently.

Deployment.

  • Consumption — deploy via ARM templates, Azure CLI, the portal. Simple.
  • Standard — deploy via Azure DevOps / GitHub Actions pipelines, source-controlled with the workflow JSON files. More setup; more rigour.

For ALM-disciplined teams, Standard's source-control story is a significant advantage.

Mixing both. A typical enterprise has both:

  • Standard Logic Apps for the integration backbone — high-volume, source-controlled, VNET-isolated.
  • Consumption Logic Apps for ad-hoc business workflows, occasional triggers, prototypes that may or may not become production.

The two interoperate cleanly — a Consumption workflow can trigger a Standard workflow and vice versa via standard mechanisms.

Choosing for Dynamics 365 integrations.

Use Consumption when:

  • Volume is low to moderate.
  • Workflows are simple, business-oriented.
  • Cost-per-execution is fine.
  • Quick to build, easy to maintain.

Use Standard when:

  • Volume is high; predictable cost matters.
  • Source control and CI/CD are mandatory.
  • VNET access to private resources is required.
  • Multiple related workflows benefit from grouping.
  • Enterprise-grade governance is needed.

Comparison with Power Automate. Power Automate (covered in earlier guides) is yet another option — even more business-user-friendly than Consumption Logic Apps, with per-user licensing instead of per-execution. The general decision tree:

  • Citizen developer, business workflow → Power Automate.
  • IT-managed integration, moderate scale → Consumption Logic Apps.
  • IT-managed integration, high scale or enterprise governance → Standard Logic Apps.
  • Heavy custom code → Azure Functions.

Operational reality. Most Dynamics 365 customers use Power Automate for the bulk of work; reach for Logic Apps when Power Automate's governance, cost, or scale models don't fit. Within Logic Apps, choose Standard for serious integrations and Consumption for everything else.

Related guides