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.
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
- Logic Apps with Dynamics 365How Azure Logic Apps complement Power Automate for Dynamics 365 integrations — when to choose which, hybrid patterns, and operational realities.
- Azure Data Factory with Dynamics 365How to use Azure Data Factory for Dynamics 365 data integration — connectors, common patterns, performance tuning, and when ADF is the right tool vs alternatives.
- Azure Functions for Dynamics 365 integrationsHow to use Azure Functions to extend and integrate Dynamics 365 — patterns, authentication, lifecycle, performance, and the trade-offs vs Power Automate.
- Azure Service Bus integration with DataverseHow Dataverse publishes change events to Azure Service Bus — registration, message format, queues vs topics, and resilient consumer patterns.
- Azure Synapse Link for DataverseHow Synapse Link replicates Dataverse data to Azure Data Lake Storage continuously — architecture, configuration, query patterns, and the path forward as Microsoft Fabric Link emerges.