Edit host and app settings for Standard logic apps in single-tenant Azure Logic Apps

Applies to: Azure Logic Apps (Standard)

In single-tenant Azure Logic Apps, the app settings for a Standard logic app specify the global configuration options that affect all the workflows in that logic app. However, these settings apply only when these workflows run in your local development environment. Locally running workflows can access these app settings as local environment variables, which are used by local development tools for values that can often change between environments. For example, these values can contain connection strings. When you deploy to Azure, app settings are ignored and aren't included with your deployment.

Your logic app also has host settings, which specify the runtime configuration settings and values that apply to all the workflows in that logic app, for example, default values for throughput, capacity, data size, and so on, whether they run locally or in Azure.

App settings, parameters, and deployment

In multitenant Azure Logic Apps, deployment depends on Azure Resource Manager templates (ARM templates), which combine and handle resource provisioning for both logic apps and infrastructure. This design poses a challenge when you have to maintain environment variables for logic apps across various dev, test, and production environments. Everything in an ARM template is defined at deployment. If you need to change just a single variable, you have to redeploy everything.

In single-tenant Azure Logic Apps, deployment becomes easier because you can separate resource provisioning between apps and infrastructure. You can use parameters to abstract values that might change between environments. By defining parameters to use in your workflows, you can first focus on designing your workflows, and then insert your environment-specific variables later. You can call and reference your environment variables at runtime by using app settings and parameters. That way, you don't have to redeploy as often.

App settings integrate with Azure Key Vault. You can directly reference secure strings, such as connection strings and keys. Similar to Azure Resource Manager templates (ARM templates), where you can define environment variables at deployment time, you can define app settings within your logic app workflow definition. You can then capture dynamically generated infrastructure values, such as connection endpoints, storage strings, and more. However, app settings have size limitations and can't be referenced from certain areas in Azure Logic Apps.

For more information about setting up your logic apps for deployment, see the following documentation:

• Create parameters for values that change in workflows between environments for single-tenant Azure Logic Apps
• DevOps deployment overview for single-tenant based logic apps
• Set up DevOps deployment for single-tenant based logic apps

Visual Studio Code project structure

In Visual Studio Code, your logic app project has either of the following types:

• Extension bundle-based (Node.js), which is the default type
• NuGet package-based (.NET), which you can convert from the default type

Based on these types, your project includes slightly different folders and files. A NuGet-based project includes a .bin folder that contains packages and other library files. A bundle-based project doesn't include the .bin folder and other files. Some scenarios require a NuGet-based project for your app to run, for example, when you want to develop and run custom built-in operations. For more information about converting your project to use NuGet, review Enable built-connector authoring.

For the default bundle-based project, your project has a folder and file structure that is similar to the following example:

MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
  || Maps 
     ||| MapName1
     ||| ...
  || Schemas
     ||| SchemaName1
     ||| ...
| WorkflowName1
  || workflow.json
  || ...
| WorkflowName2
  || workflow.json
  || ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json

At your project's root level, you can find the following files and folders with other items:

Reference for app settings - local.settings.json

In Visual Studio Code, at your logic app project's root level, the local.settings.json file contain global configuration options that affect all workflows in that logic app while running in your local development environment. When your workflows run locally, these settings are accessed as local environment variables, and their values can often change between the various environments where you run your workflows. To view and manage these settings, review Manage app settings - local.settings.json.

App settings in Azure Logic Apps work similarly to app settings in Azure Functions or Azure Web Apps. If you've used these other services before, you might already be familiar with app settings. For more information, review App settings reference for Azure Functions and Work with Azure Functions Core Tools - Local settings file.

Manage app settings - local.settings.json

To add, update, or delete app settings, select and review the following sections for Azure portal, Visual Studio Code, Azure CLI, or ARM (Bicep) template. For app settings specific to logic apps, review the reference guide for available app settings - local.settings.json.

az logicapp config appsettings list --name MyLogicApp --resource-group MyResourceGroup

az logicapp config appsettings set --name MyLogicApp --resource-group MyResourceGroup --settings CUSTOM_LOGIC_APP_SETTING=12345 

Reference for host settings - host.json

In Visual Studio Code, at your logic app project's root level, the host.json metadata file contains the runtime settings and default values that apply to all workflows in a logic app resource whether running locally or in Azure. To view and manage these settings, review Manage host settings - host.json. You can also find related limits information in the Limits and configuration for Azure Logic Apps documentation.

Job orchestration throughput

These settings affect the throughput and capacity for single-tenant Azure Logic Apps to run workflow operations.

Both of the following settings are used to manually stop and immediately delete the specified workflows in Standard logic app.

The following example shows the syntax for these settings where each workflow ID is followed by a colon (:) and separated by a semicolon (;):

"Jobs.CleanupJobPartitionPrefixes": "<workflow-ID-1>:; <workflow-ID-2:",
"Jobs.SuspendedJobPartitionPrefixes": "<workflow-ID-1>:; <workflow-ID-2>:"

Target-based scaling

Single-tenant Azure Logic Apps gives you the option to select your preferred compute resources and set up your logic app resources to dynamically scale based on varying workload demands. The target-based scaling model used by Azure Logic Apps includes settings that you can use to fine-tune the model's underlying dynamic scaling mechanism, which can result in faster scale-out and scale-in times. For more information about the target-based scaling model, see Target-based scaling for Standard workflows in single-tenant Azure Logic Apps.

Considerations

• Target-based scaling isn't available or supported for Standard workflows running on an App Service Environment or Consumption plan.

• If you have scale-in requests without any scale-out requests, Azure Logic Apps uses the maximum scale-in value. Target-based scaling can scale down unused worker instances faster, resulting in more efficient resource usage.

Requirements

• Your logic apps must use Azure Functions runtime version 4.3.0 or later.

• Your logic app workflows must use single-tenant Azure Logic Apps runtime version 1.55.1 or later.

Target-based scaling settings in host.json

TargetConcurrency example

{
   "version": "2.0",
   "extensionBundle": {
      "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
      "version": "[1.*, 2.0.0)"
   },
   "extensions": {
      "workflow": {
         "Settings": {
            "Runtime.TargetScaler.TargetConcurrency": "280"
         }
      }
   }
}

TargetScalingCPU example

{
   "version": "2.0",
   "extensionBundle": {
      "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
      "version": "[1.*, 2.0.0)"
   },
   "extensions": {
      "workflow": {
         "Settings": {
            "Runtime.TargetScaler.TargetScalingCPU": "76"
         }
      }
   }
}

TargetScalingFactor example

{
   "version": "2.0",
   "extensionBundle": {
      "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
      "version": "[1.*, 2.0.0)"
   },
   "extensions": {
      "workflow": {
         "Settings": {
            "Runtime.TargetScaler.TargetScalingFactor": "0.62"
         }
      }
   }
}

Disable target-based scaling

By default, target-based scaling is automatically enabled. To opt out from using target-based scaling and revert back to incremental scaling, add the app setting named TARGET_BASED_SCALING_ENABLED and set the value set to 0 in your Standard logic app resource using the Azure portal or in your logic app project's local.settings.json file using Visual Studio Code. For more information, see Manage app settings - local.settings.json.

Recurrence-based triggers

Trigger concurrency

The following settings work only for workflows that start with a recurrence-based trigger for built-in, service provider-based connectors. For a workflow that starts with a function-based trigger, you might try to set up batching where supported. However, batching isn't always the correct solution. For example, with Azure Service Bus triggers, a batch might hold onto messages beyond the lock duration. As a result, any action, such as complete or abandon, fails on such messages.

Run duration and history retention

Run actions

Inputs and outputs

Pagination

Chunking

Store content inline or use blobs

For each loops

Until loops

Variables

Built-in HTTP operations

Built-in HTTP Webhook operations

Built-in Azure Storage operations

Blob storage

Table and queue storage

File share

Built-in Azure Functions operations

Built-in Azure Service Bus operations

Built-in SFTP operations

Managed connector operations

Retry policy for all other operations

Limitations

• Maximum content size

  By default, built-in triggers, such as HTTP or Request, are limited to the message size described in Limits and configuration reference - Messages. To handle files larger than the limit, try uploading your content as a blob to Azure Blob Storage, and then get your content using the Azure Blob connector.

Manage host settings - host.json

You can add, update, or delete host settings, which specify the runtime configuration settings and values that apply to all the workflows in that logic app, such as default values for throughput, capacity, data size, and so on, whether they run locally or in Azure. For host settings specific to logic apps, review the reference guide for available runtime and deployment settings - host.json.

Azure portal - host.json

To review the host settings for your single-tenant based logic app in the Azure portal, follow these steps:

1. In the Azure portal search box, find and open your logic app.

2. On your logic app menu, under Development Tools, select Advanced Tools.

3. On the Advanced Tools page, select Go, which opens the Kudu environment for your logic app.

4. On the Kudu toolbar, from the Debug console menu, select CMD.

5. In the Azure portal, stop your logic app.

   1. On your logic app menu, select Overview.

   2. On the Overview pane's toolbar, select Stop.

6. On your logic app menu, under Development Tools, select Advanced Tools.

7. On the Advanced Tools pane, select Go, which opens the Kudu environment for your logic app.

8. On the Kudu toolbar, open the Debug console menu, and select CMD.

   A console window opens so that you can browse to the wwwroot folder using the command prompt. Or, you can browse the directory structure that appears above the console window.

9. Browse along the following path to the wwwroot folder: ...\home\site\wwwroot.

10. Above the console window, in the directory table, next to the host.json file, select Edit.

11. After the host.json file opens, review any host settings that were previously added for your logic app.

    For more information about host settings, review the reference guide for available host settings - host.json.

To add a setting, follow these steps:

1. Before you add or edit settings, stop your logic app in the Azure portal.

   1. On your logic app menu, select Overview.
   2. On the Overview pane's toolbar, select Stop.

2. Return to the host.json file. Under the extensionBundle object, add the extensions object, which includes the workflow and settings objects, for example:

   {
      "version": "2.0",
      "extensionBundle": {
         "id": "Microsoft.Azure.Functions.ExtensionBundle",
         "version": "[1.*, 2.0.0)"
      },
      "extensions": {
         "workflow": {
            "settings": {
            }
         }
      }
   }
   

3. In the settings object, add a flat list with the host settings that you want to use for all the workflows in your logic app, whether those workflows run locally or in Azure, for example:

   {
      "version": "2.0",
      "extensionBundle": {
         "id": "Microsoft.Azure.Functions.ExtensionBundle",
         "version": "[1.*, 2.0.0)"
      },
      "extensions": {
         "workflow": {
            "settings": {
               "Runtime.Trigger.MaximumWaitingRuns": "100"
            }
         }
      }
   }
   

4. When you're done, remember to select Save.

5. Now, restart your logic app. Return to your logic app's Overview page, and select Restart.

Visual Studio Code - host.json

To review the host settings for your logic app in Visual Studio Code, follow these steps:

1. In your logic app project, at the root project level, find and open the host.json file.

2. In the extensions object, under workflows and settings, review any host settings that were previously added for your logic app. Otherwise, the extensions object won't appear in the file.

   For more information about host settings, review the reference guide for available host settings - host.json.

To add a host setting, follow these steps:

1. In the host.json file, under the extensionBundle object, add the extensions object, which includes the workflow and settings objects, for example:

   {
      "version": "2.0",
      "extensionBundle": {
         "id": "Microsoft.Azure.Functions.ExtensionBundle",
         "version": "[1.*, 2.0.0)"
      },
      "extensions": {
         "workflow": {
            "settings": {
            }
         }
      }
   }
   

2. In the settings object, add a flat list with the host settings that you want to use for all the workflows in your logic app, whether those workflows run locally or in Azure, for example:

   {
      "version": "2.0",
      "extensionBundle": {
         "id": "Microsoft.Azure.Functions.ExtensionBundle",
         "version": "[1.*, 2.0.0)"
      },
      "extensions": {
         "workflow": {
            "settings": {
               "Runtime.Trigger.MaximumWaitingRuns": "100"
            }
         }
      }
   }
   

Next steps

• Create parameters for values that change in workflows between environments for single-tenant Azure Logic Apps
• Set up DevOps deployment for single-tenant Azure Logic Apps