Migrating Logic Apps from Consumption to Standard: Real Lessons and Big Wins – part 3

A Journey to Logic app Standard

Welcome to the third part of our series on migrating from Logic App Consumption to Logic App Standard. In the previous posts (Part 2 & Part 3), we discussed initial considerations, key differences, and helpful tips for making the transition. Here, we’ll dive into more advanced topics and differences, focusing on key differences, insights and improvements that can enhance your Logic App Standard experience.

Run History Retention

Run retention refers to the number of days you can look back in history to view an executed run. This feature is useful for troubleshooting and compliance purposes, as historical data needs to be retained for specific periods.

Logic App Standard offers greater control over workflow run history retention. By default, each workflow’s run history is kept for 90 days, and stored in an Azure Storage account. This can be configured per workflow to reduce storage costs if long-term run history isn’t needed. Lowering retention settings can significantly cut down costs, especially for workflows generating a high volume of data. Here’s how to set it up the configuration is different compared to a logic app consumption!

In the host.json file: the parameter “Runtime.FlowRetentionThreshold” configures the entire retention policy for all workflows under this logic app.

'Runtime.FlowRetentionThreshold': 7

The same setting is also available for a specific workflow:

'Workflows.<workflowname>.RuntimeConfiguration.RetentionInDays’: 14

See this blog post from Microsoft for detailed instructions.

Enhanced RBAC Access Control

Logic App Standard brings expanded Role-Based Access Control (RBAC) capabilities. One can assign roles at the logic app level, not the workflow level, which is very different compared to logic app consumption. Ensure to evaluate this for making a decision on how many logic app instances you will define.

Microsoft has introduced new RBAC roles and created a “Developer” role specifically for Logic App Standard, allowing users to manage settings, access Kudu, maps, and perform other actions without the broader permissions of the “Contributor” role. This role-based approach provides a finer level of control, ideal for team environments.

For a detailed explanation of the new RBAC roles, check out this video by Kent Weare below and Micosoft’s official announcement.

Environment Variables Support

Logic App Standard now provides seamless integration with Azure Key Vault and App Configuration directly from the app settings, aligning Logic Apps with other Azure services like Functions and Web Apps. This is a significant improvement for DevOps teams and mixed development environments, as it streamlines environment-specific configuration management, ensuring Logic Apps adopt the same familiar setup as other Azure applications.

However, this feature introduces some complexity, as Logic App Standard offers two locations for environment variable configurations: parameters and environment variables.

Parameters are accessible in the Logic App designer, making them useful for values that developers need to reference during design. You can actually mix and match them, as I prefer to save all values in the app settings.

Step 1: Define Parameters in the Designer Define the parameters in the designer for easy access:

"Custom.BnpLoginPassword":
    "type": "String",
    "value": "@appsetting('Custom.BnpLoginPassword’)"
  }

Step 2: Configure App Settings with Actual Values or Key Vault References In the app settings, provide the actual value or a reference to the Key Vault, if applicable:

  {
    "name": "Custom.BnpLoginPassword",
    "value": "@Microsoft.KeyVault(VaultName=yourkeyvaultname;SecretName=BnpLoginPassword)",
    "slotSetting": false
  }

Or one can even refer to Azure App Configuration Settings now:

  {
    "name": "Custom.BnpLoginPassword",
    "value": "@Microsoft.AppConfiguration(Endpoint=https://yourappconfighere.azconfig.io; Key=BnpLoginInterval)",
    "slotSetting": false
  }

Improved Logging and Error Analysis

With access to Kudu logs, Logic App Standard offers deeper visibility into both workflow and host-level logs, providing robust support for troubleshooting. Engineers can easily track logs for the host environment and individual workflows, which simplifies debugging.

For real-time monitoring, the Log Stream section under “Monitor” provides live logs, including App Insights and filesystem logs.

Health Checks for Proactive Monitoring

Health checks, a new addition to Logic App Standard, allow engineers to create endpoints that monitor the availability of dependencies—such as APIs, databases, or storage accounts. This feature is invaluable for proactive monitoring, as it offers a quick view of system dependencies, ensuring that each critical component is functioning as expected.

How Does Health Check Works for Logic Apps?
Health checks ensure the reliability of your Logic Apps by monitoring their endpoints at regular intervals. When a specified endpoint is provided, the Health Check pings it every minute across all active Logic App instances.

1. If an instance fails to respond with a status code between 200 and 299 for a set number of attempts (default is 10, but configurable to as low as 2), it is flagged as unhealthy and removed from the load balancer.
2. The removed instance continues to be monitored, and if it starts returning healthy responses, it is automatically reinstated.

Microsoft offers an excellent article on this topic, originally written for .NET App Services but equally relevant for Logic App Standard: Monitor App Service Instances by using Health Check.