Differences between Standard single-tenant logic apps versus Consumption multitenant logic apps

Azure Logic Apps is a cloud-based platform for creating and running automated logic app workflows that integrate your apps, data, services, and systems. With this platform, you can quickly develop highly scalable integration solutions for your enterprise and business-to-business (B2B) scenarios. When you create a logic app resource, you select either the Consumption workflow type or Standard workflow type. A Consumption logic app can have only one workflow that runs in multitenant Azure Logic Apps or an integration service environment. A Standard logic app can have one or multiple workflows that run in single-tenant Azure Logic Apps or an App Service Environment v3 (ASE v3).

Before you choose which logic app resource to create, review the following guide to learn how the logic app workflow types compare with each other. You can then make a better choice about which logic app workflow and environment best suits your scenario, solution requirements, and the destination where you want to deploy and run your workflows.

If you're new to Azure Logic Apps, review What is Azure Logic Apps? and What is a logic app workflow?.

Logic app workflow types and environments

The following table summarizes the differences between a Consumption logic app workflow and Standard logic app workflow. You also learn how the single-tenant environment differs from the multitenant environment and an integration service environment (ISE) for deploying, hosting, and running your workflows.

Standard logic app and workflow

The Standard logic app and workflow is powered by the redesigned single-tenant Azure Logic Apps runtime. This runtime uses the Azure Functions extensibility model and is hosted as an extension on the Azure Functions runtime. This design provides portability, flexibility, and more performance for your logic app workflows plus other capabilities and benefits inherited from the Azure Functions platform and the Azure App Service ecosystem. For example, you can create, deploy, and run single-tenant based logic apps and their workflows in Azure App Service Environment v3 (Windows plans only).

The Standard logic app introduces a resource structure that can host multiple workflows, similar to how an Azure function app can host multiple functions. With a 1-to-many mapping, workflows in the same logic app and tenant share compute and processing resources, providing better performance due to their proximity. This structure differs from the Consumption logic app resource where you have a 1-to-1 mapping between the logic app resource and a workflow.

To learn more about portability, flexibility, and performance improvements, continue reviewing the following sections. For more information about the single-tenant Azure Logic Apps runtime and Azure Functions extensibility, review the following documentation:

• Azure Logic Apps Running Anywhere - Runtime Deep Dive
• Introduction to Azure Functions
• Azure Functions triggers and bindings

Portability and flexibility

When you create a Standard logic app and workflow, you can deploy and run your workflow in other environments, such as Azure App Service Environment v3 (Windows plans only). If you use Visual Studio Code with the Azure Logic Apps (Standard) extension, you can locally develop, build, and run your workflow in your development environment without having to deploy to Azure. If your scenario requires containers, you can create single tenant logic apps using Azure Arc-enabled Logic Apps. For more information, see What is Azure Arc enabled Logic Apps?

These capabilities provide major improvements and substantial benefits compared to the multitenant model, which requires you to develop against an existing running resource in Azure. The multitenant model for automating Consumption logic app resource deployment is based on Azure Resource Manager templates (ARM templates), which combine and handle resource provisioning for both apps and infrastructure.

With the Standard logic app resource, deployment becomes easier because you can separate app deployment from infrastructure deployment. You can package the single-tenant Azure Logic Apps runtime and your workflows together as part of your logic app resource or project. You can use generic steps or tasks that build, assemble, and zip your logic app resources into ready-to-deploy artifacts. To deploy your infrastructure, you can still use ARM templates to separately provision those resources along with other processes and pipelines that you use for those purposes.

To deploy your app, copy the artifacts to the host environment and then start your apps to run your workflows. Or, integrate your artifacts into deployment pipelines using the tools and processes that you already know and use. That way, you can deploy using your own chosen tools, no matter the technology stack that you use for development.

By using standard build and deploy options, you can focus on app development separately from infrastructure deployment. As a result, you get a more generic project model where you can apply many similar or the same deployment options that you use for a generic app. You also benefit from a more consistent experience when you build deployment pipelines for your apps and when you run the required tests and validations before you publish to production.

Performance

With a Standard logic app, you can create and run multiple workflows in the same single logic app resource and tenant. With this 1-to-many mapping, these workflows share resources, such as compute, processing, storage, and network, providing better performance due to their proximity.

The Standard logic app resource and single-tenant Azure Logic Apps runtime provide another significant improvement by making the more popular managed connectors available as built-in connector operations. For example, you can use built-in connector operations for Azure Service Bus, Azure Event Hubs, SQL Server, and others. Meanwhile, the managed connector versions are still available and continue to work.

When you use the new built-in connector operations, you create connections called built-in connections or service provider connections. Their managed connection counterparts are called API connections, which are created and run separately as Azure resources that you also have to then deploy by using ARM templates. Built-in operations and their connections run locally in the same process that runs your workflows. Both are hosted on the single-tenant Azure Logic Apps runtime. As a result, built-in operations and their connections provide better performance due to proximity with your workflows. This design also works well with deployment pipelines because the service provider connections are packaged into the same build artifact.

Data residency

Standard logic app resources are hosted in single-tenant Azure Logic Apps, which doesn't store, process, or replicate data outside the region where you deploy these logic app resources, meaning that data in your workflows stay in the same region where you create and deploy their parent resources.

Direct access to resources in Azure virtual networks

Workflows that run in either single-tenant Azure Logic Apps or in an integration service environment (ISE) can directly access secured resources such as virtual machines (VMs), other services, and systems that exist in an Azure virtual network.

Both single-tenant Azure Logic Apps and an ISE are dedicated instances of the Azure Logic Apps service, use dedicated resources, and run separately from multitenant Azure Logic Apps. Running workflows in a dedicated instance helps reduce the impact that other Azure tenants might have on app performance, also known as the "noisy neighbors" effect.

Single-tenant Azure Logic Apps and an ISE also provide the following benefits:

• Your own static IP addresses, which are separate from the static IP addresses that are shared by the logic apps in the multitenant Azure Logic Apps. You can also set up a single public, static, and predictable outbound IP address to communicate with destination systems. That way, you don't have to set up extra firewall openings at those destination systems for each ISE.

• Increased limits on run duration, storage retention, throughput, HTTP request and response timeouts, message sizes, and custom connector requests. For more information, review Limits and configuration for Azure Logic Apps.

Create, build, and deploy options

To create a logic app resource based on the environment that you want, you have multiple options, for example:

Single-tenant environment

Multitenant environment

Integration service environment

Although your development experiences differ based on whether you create Consumption or Standard logic app resources, you can find and access all your deployed logic apps under your Azure subscription.

For example, in the Azure portal, the Logic apps page shows both Consumption and Standard logic app resources. In Visual Studio Code, deployed logic apps appear under your Azure subscription, but Consumption logic apps appear in the Azure window under the Azure Logic Apps (Consumption) extension, while Standard logic apps appear under the Resources section.

Stateful and stateless workflows

Within a Standard logic app, you can create the following workflow types:

• Stateful

  Create a stateful workflow when you need to keep, review, or reference data from previous events. These workflows save all the operations' inputs, outputs, and states to external storage. This information makes reviewing the workflow run details and history possible after each run finishes. Stateful workflows provide high resiliency if outages happen. After services and systems are restored, you can reconstruct interrupted runs from the saved state and rerun the workflows to completion. Stateful workflows can continue running for much longer than stateless workflows.

  By default, stateful workflows in both multitenant and single-tenant Azure Logic Apps run asynchronously. All HTTP-based actions follow the standard asynchronous operation pattern. After an HTTP action calls or sends a request to an endpoint, service, system, or API, the request receiver immediately returns a "202 ACCEPTED" response. This code confirms that the receiver accepted the request but hasn't finished processing. The response can include a location header that specifies the URI and a refresh ID that the caller can use to poll or check the status for the asynchronous request until the receiver stops processing and returns a "200 OK" success response or other non-202 response. However, the caller doesn't have to wait for the request to finish processing and can continue to run the next action. For more information, see Asynchronous microservice integration enforces microservice autonomy.

• Stateless

  Create a stateless workflow when you don't need to keep, review, or reference data from previous events in external storage after each run finishes for later review. These workflows save all the inputs and outputs for each action and their states in memory only, not in external storage. As a result, stateless workflows have shorter runs that usually finish in 5 minutes or less, faster performance with quicker response times, higher throughput, and reduced running costs because external storage doesn't save the workflow run details and history. However, if outages happen, interrupted runs aren't automatically restored, so the caller needs to manually resubmit interrupted runs.

  A stateless workflow provides the best performance when handling data or content that doesn't exceed 64 KB in total size, such as a file. Larger content sizes, such as multiple large attachments, might significantly slow your workflow's performance or even cause your workflow to crash due to out-of-memory exceptions. If your workflow might have to handle larger content sizes, use a stateful workflow instead.

  In stateless workflows, managed connector actions are available, but managed connector triggers are unavailable. So, to start your workflow, select a built-in trigger instead, such as the Request, Event Hubs, or Service Bus trigger. These triggers run natively on the Azure Logic Apps runtime. The Recurrence trigger is unavailable for stateless workflows and is available only for stateful workflows. For more information about limited, unavailable, or unsupported triggers, actions, and connectors, see Changed, limited, unavailable, or unsupported capabilities.

  Stateless workflows run only synchronously, so they don't use the standard asynchronous operation pattern used by stateful workflows. Instead, all HTTP-based actions that return a "202 ACCEPTED" response continue to the next step in the workflow execution. If the response includes a location header, a stateless workflow won't poll the specified URI to check the status. To follow the standard asynchronous operation pattern, use a stateful workflow instead.

  For easier debugging, you can enable run history for a stateless workflow, which has some impact on performance, and then disable the run history when you're done. For more information, see Create single-tenant based workflows in Visual Studio Code or Create single-tenant based workflows in the Azure portal.

Summary differences between stateful and stateless workflows

Nested behavior differences between stateful and stateless workflows

You can make a workflow callable from other workflows that exist in the same Standard logic app by using the Request trigger, HTTP Webhook trigger, or managed connector triggers that have the ApiConnectionWebhook type and can receive HTTPS requests.

The following list describes the behavior patterns that nested workflows can follow after a parent workflow calls a child workflow:

• Asynchronous polling pattern

  The parent workflow doesn't wait for the child workflow to respond to their initial call. However, the parent continually checks the child's run history until the child finishes running. By default, stateful workflows follow this pattern, which is ideal for long-running child workflows that might exceed request timeout limits.

• Synchronous pattern ("fire and forget")

  The child workflow acknowledges the parent workflow's call by immediately returning a 202 ACCEPTED response. However, the parent doesn't wait for the child to return results. Instead, the parent continues on to the next action in the workflow and receives the results when the child finishes running. Child stateful workflows that don't include a Response action always follow the synchronous pattern and provide a run history for you to review.

  To enable this behavior, in the workflow's JSON definition, set the operationOptions property to DisableAsyncPattern. For more information, see Trigger and action types - Operation options.

• Trigger and wait

  Stateless workflows run in memory. So when a parent workflow calls a child stateless workflow, the parent waits for a response that returns the results from the child. This pattern works similarly to using the built-in HTTP trigger or action to call a child workflow. Child stateless workflows that don't include a Response action immediately return a 202 ACCEPTED response, but the parent waits for the child to finish before continuing to the next action. These behaviors apply only to child stateless workflows.

The following table identifies the child workflow's behavior based on whether the parent and child are stateful, stateless, or are mixed workflow types. The list after the table

Other single-tenant model capabilities

The single-tenant model and Standard logic app include many current and new capabilities, for example:

• Create logic apps and their workflows from hundreds of managed connectors for Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) apps and services plus connectors for on-premises systems.

  • More managed connectors are now available as built-in connectors in Standard workflows. The built-in versions run natively on the single-tenant Azure Logic Apps runtime. Some built-in connectors are also informally known as service provider connectors. For a list, review Built-in connectors in Consumption and Standard.

  • You can create your own custom built-in connectors for any service that you need by using the single-tenant Azure Logic Apps extensibility framework. Similar to built-in connectors such as Azure Service Bus and SQL Server, custom built-in connectors provide higher throughput, low latency, and local connectivity because they run in the same process as the single-tenant runtime. However, custom built-in connectors aren't similar to custom managed connectors, which aren't currently supported. For more information, review Custom connector overview and Create custom built-in connectors for Standard logic apps in single-tenant Azure Logic Apps.

  • You can use the following actions for Liquid Operations and XML Operations without an integration account. These operations include the following actions:

    • XML: Transform XML and XML Validation

    • Liquid: Transform JSON To JSON, Transform JSON To TEXT, Transform XML To JSON, and Transform XML To Text

    Note

    To use these actions in Standard workflows, you need to have Liquid maps, XML maps, or XML schemas. You can upload these artifacts in the Azure portal from your logic app's resource menu, under Artifacts, which includes the Schemas and Maps sections. Or, you can add these artifacts to your Visual Studio Code project's Artifacts folder using the respective Maps and Schemas folders. You can then use these artifacts across multiple workflows within the same logic app.

  • Standard logic app workflows can run anywhere because Azure Logic Apps generates Shared Access Signature (SAS) connection strings that these logic apps can use for sending requests to the cloud connection runtime endpoint. Azure Logic Apps saves these connection strings with other application settings so that you can easily store these values in Azure Key Vault when you deploy in Azure.

  • Standard logic app workflows support enabling both the system-assigned managed identity and multiple user-assigned managed identities at the same time, although you can select only one identity to use at a time. While built-in, service provider-based connectors support using the system-assigned identity, most currently don't support selecting user-assigned managed identities for authentication, except for SQL Server and the HTTP connectors.

    Note

    By default, the system-assigned identity is already enabled to authenticate connections at run time. This identity differs from the authentication credentials or connection string that you use when you create a connection. If you disable this identity, connections won't work at run time. To view this setting, on your logic app's menu, under Settings, select Identity.

• You can locally run, test, and debug your logic apps and their workflows in the Visual Studio Code development environment.

  Before you run and test your logic app, you can make debugging easier by adding and using breakpoints inside the workflow.json file for a workflow. However, breakpoints are supported only for actions at this time, not triggers. For more information, see Create single-tenant based workflows in Visual Studio Code.

• Directly publish or deploy logic apps and their workflows from Visual Studio Code to various hosting environments such as Azure and Azure Arc enabled Logic Apps.

• Enable diagnostics logging and tracing capabilities for your logic app by using Application Insights when supported by your Azure subscription and logic app settings.

• Access networking capabilities, such as connect and integrate privately with Azure virtual networks, similar to Azure Functions when you create and deploy your logic apps using the Azure Functions Premium plan. For more information, review the following documentation:

  • Azure Functions networking options

  • Azure Logic Apps Running Anywhere - Networking possibilities with Azure Logic Apps

• Regenerate access keys for managed connections used by individual workflows in a Standard logic app. For this task, follow the same steps for a Consumption logic app but at the workflow level, not the logic app resource level.

Built-in connectors for Standard

A Standard workflow can use many of the same built-in connectors as a Consumption workflow, but not all. Vice versa, a Standard workflow has many built-in connectors that aren't available in a Consumption workflow.

For example, a Standard workflow has both managed connectors and built-in connectors for Azure Blob, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, DB2, FTP, MQ, SFTP, SQL Server, and others. Although a Consumption workflow doesn't have these same built-in connector versions, other built-in connectors such as Azure API Management and Azure App Services are available.

In single-tenant Azure Logic Apps, built-in connectors with specific attributes are informally known as service providers. Some built-in connectors support only a single way to authenticate a connection to the underlying service. Other built-in connectors can offer a choice, such as using a connection string, Microsoft Entra ID, or a managed identity. All built-in connectors run in the same process as the redesigned Azure Logic Apps runtime. For more information, review the built-in connector list for Standard logic app workflows.

Changed, limited, unavailable, or unsupported capabilities

For the Standard logic app workflow, these capabilities have changed, or they're currently limited, unavailable, or unsupported:

• Triggers and actions: Built-in triggers and actions run natively in Azure Logic Apps, while managed connectors are hosted and run using shared resources in Azure. For Standard workflows, some built-in triggers and actions are currently unavailable, such as Sliding Window, Azure App Service, and Azure API Management. To start a stateful or stateless workflow, use a built-in trigger such as the Request, Event Hubs, or Service Bus trigger. The Recurrence trigger is available for stateful workflows, but not stateless workflows. In the designer, built-in triggers and actions appear with the In-App label, while managed connector triggers and actions appear with the Shared label.

  For stateless workflows, managed connector actions are available, but managed connector triggers are unavailable. Although you can enable managed connectors for stateless workflows, the designer doesn't show any managed connector triggers for you to add.

  Note

  To run locally in Visual Studio Code, webhook-based triggers and actions require additional setup. For more information, see Create single-tenant based workflows in Visual Studio Code.

  • The following triggers and actions have either changed or are currently limited, unsupported, or unavailable:

    • The built-in action, Azure Functions - Choose an Azure function is now Azure Functions Operations - Call an Azure function. This action currently works only for functions that are created from the HTTP Trigger template.

      In the Azure portal, you can select an HTTP trigger function that you can access by creating a connection through the user experience. If you inspect the function action's JSON definition in code view or the workflow.json file using Visual Studio Code, the action refers to the function by using a connectionName reference. This version abstracts the function's information as a connection, which you can find in your logic app project's connections.json file, which is available after you create a connection in Visual Studio Code.

      Note

      In the single-tenant model, the function action supports only query string authentication. Azure Logic Apps gets the default key from the function when making the connection, stores that key in your app's settings, and uses the key for authentication when calling the function.

      As in the multitenant model, if you renew this key, for example, through the Azure Functions experience in the portal, the function action no longer works due to the invalid key. To fix this problem, you need to recreate the connection to the function that you want to call or update your app's settings with the new key.

    • The built-in action, Inline Code, is renamed Inline Code Operations, no longer requires an integration account, and has updated limits.

    • The built-in action, Azure Logic Apps - Choose a Logic App workflow is now Workflow Operations - Invoke a workflow in this workflow app.

    • The Gmail connector currently isn't supported.

    • Custom managed connectors currently aren't currently supported. However, you can create custom built-in operations when you use Visual Studio Code. For more information, review Create single-tenant based workflows using Visual Studio Code.

    • A Standard logic app workflow can have only one trigger and doesn't support multiple triggers.

• Authentication: The following authentication types are currently unavailable for Standard workflows:

  • Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) for inbound calls to request-based triggers, such as the Request trigger and HTTP Webhook trigger.

  • Managed identity authentication: Both system-assigned and user-assigned managed identity support is available. By default, the system-assigned managed identity is automatically enabled. However, most built-in, service provider-based connectors don't currently support selecting user-assigned managed identities for authentication.

• XML transformation: Only XSLT 1.0 is currently supported.

• Breakpoint debugging in Visual Studio Code: Although you can add and use breakpoints inside the workflow.json file for a workflow, breakpoints are supported only for actions at this time, not triggers. For more information, see Create single-tenant based workflows in Visual Studio Code.

• Trigger history and run history: For a Standard logic app, trigger history and run history in the Azure portal appears at the workflow level, not the logic app resource level. For more information, review Create single-tenant based workflows using the Azure portal.

• Backup and restore for workflow run history: Standard logic apps currently don't support backup and restore for workflow run history.

• Deployment targets: You can't deploy a Standard logic app resource to an integration service environment (ISE) nor to Azure deployment slots.

• Azure API Management: You currently can't import a Standard logic app resource into Azure API Management. However, you can import a Consumption logic app resource.

• Authentication to backend storage: Single-tenant Azure Logic Apps relies only on storage access keys to connect with the backend Azure Storage account. Alternative authentication methods, such as Microsoft Entra ID (Enterprise ID) and managed identity, currently aren't supported. So, when you deploy an Azure storage account alongside a Standard logic app, make sure that you enable storage access keys.

Strict network and firewall traffic permissions

If your environment has strict network requirements or firewalls that limit traffic, you have to allow access for any trigger or action connections in your workflows. You can optionally allow traffic from service tags and use the same level of restrictions or policies as Azure App Service. You also need to find and use the fully qualified domain names (FQDNs) for your connections. For more information, review the corresponding sections in the following documentation:

• Firewall permissions for single tenant logic apps - Azure portal
• Firewall permissions for single tenant logic apps - Visual Studio Code

Next steps

• Create single-tenant based workflows in the Azure portal
• Create single-tenant based workflows in Visual Studio Code

We'd also like to hear about your experiences with single-tenant Azure Logic Apps!

• For bugs or problems, create your issues in GitHub.
• For questions, requests, comments, and other feedback, use this feedback form.