Parameterizing Managed Connections with Logic Apps Standard

Posted by

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

Parameterizing Managed Connections with Logic Apps Standard




Logic Apps Standard introduces a resource structure that can host multiple workflows within the same application. With a one-to-many mapping, workflows in the same logic app and tenant share computing and processing resources, providing better performance due to their proximity. This model also simplifies deployment of logic apps, with a stronger separation of concerns between the infrastructure – the Logic App Standard app, associated App Service plans, storage repositories – and the groups of workflows that are executed under the app, simplifying the process of deployment automation for Logic Apps, as customer can follow practices that they already using for similar resources like Web Apps and Azure Functions.

One of the common activities when getting Logic Apps Standard ready for a DevOps pipeline is to parametrize values that can change between environments, like environment specific variables and connection references.

While environment specific variables could be easily achieved by the combination of workflow parameters and app settings, connection reference could be hard to achieve. Connection references usually have a combination of common values which are environment specific - subscription IDs, resource groups names, for example- that must be combined with fixed values that are the same in each environment – connector type, connector name – to create a specific path or identifier. This interpolation was not available until now.

With the latest update of the logic apps extension (starting on version 1.0.40) parametrization of the Logic Apps Standard apps becomes easier, as now both runtime and designer support the interpolation of app settings or parameter references. This simplifies the management of those files.


Anatomy of an Azure Managed connection reference in connections.json


A typical Azure Managed connection reference generated by the Logic Apps’ designer looks like this:


"<connectionname>": { "api": { "id": "/subscriptions/<subscriptionID>/providers/Microsoft.Web/locations/australiaeast/managedApis/<connectorname>" }, "connection": { "id": "/subscriptions/<subscriptionID>/resourceGroups/<resourcegroupname>/providers/Microsoft.Web/connections/<connectionname>" }, "connectionRuntimeUrl": "<auto-generated url>", "authentication": { "type": "Raw", "scheme": "Key", "parameter": "@appsetting('<connectionname>-connectionKey')" } }






Defines the type of the connector that must invoked in a specific <subscriptionID> and <locationame>,


Defines the unique identifier for this connector, deployed in a specific <subscriptionID>, <resourcegroupname> using a <connectionname>


This is an auto generated endpoint that point to the deployed connection – this is the endpoint that is used during runtime to invoke the connection from a workflow.


Defines how the logic app will authenticate when calling the connectionRuntimeUrl, proving that this Logic App has permission to access the connection. The default when running this locally is Raw authentication, since locally there is no managed identity. When deploying this to a logic app standard app in the cloud this value should change to managed identity.


The snippet below is an example of a connection to azurequeues (with subscription id obfuscated):


"azurequeues": { "api": { "id": "/subscriptions/********-****-****-****-************/providers/Microsoft.Web/locations/australiaeast/managedApis/azurequeues" }, "connection": { "id": "/subscriptions/********-****-****-****-************/resourceGroups/myresourcegroup/providers/Microsoft.Web/connections/azurequeues-1" }, "connectionRuntimeUrl": "https://****************.**********************************/", "authentication": { "type": "Raw", "scheme": "Key", "parameter": "@appsetting('azurequeues-connectionKey')" }


Common application settings


For new managed connections to be available in VS Code, you must provide a resource group where the logic app will deploy those connections. This is done by selecting the “Use Connections from Azure” in the context menu of any workflow. This process only needs to be done once. By the time this is done, the following entries are added in the





The id of the tenant where the connections will be deployed when created from the designer.


The subscription where the connections will be deployed when created from the designer


The resource group where the connections will be deployed when created from the designer


The region where the connections will be deployed when created from the designer


This identifies the base URL for the management API – used to setup the authentication between logic apps and the connection


As an example, after selecting “Use Connections from Azure” and provide the value, you will find those items in your local.appsettings.json file:


    "WORKFLOWS_TENANT_ID": "********-****-****-****-************",
    "WORKFLOWS_SUBSCRIPTION_ID": "********-****-****-****-************",
    "WORKFLOWS_RESOURCE_GROUP_NAME": " myresourcegroup",
    "WORKFLOWS_LOCATION_NAME": "australiaeast",


Why is this important? Because since those values are going to be available, anyway, we can use them to parameterize the connections, instead of trying to create new parameters for the same values.


Parameterizing existing connections


To configure an existing managed connection created in connections.json with the values that can be easily replaced between environments, replace the following values in the connection with values from app settings:




Original value


New Value





Original value


New Value



connectionRuntimeURL can’t be parameterized like the items below, but should be moved to parameters.json, so you can have a different value per environment without having to change connections.json




Original value


New Value



Make sure that you include the following new parameter:


"<connectionname>-RuntimeUrl": { "type": "String", "value": "<autogenerated URL>" }


For deployments in other environments, the connectionRuntimeUrl can be obtained as an output of the ARM template that deploys the connection. You can use this to automate the update of parameters.json. You can refer to this article to find more about how to capture connectionRuntimeUrl as an output from the ARM template execution.

Finally, the last value that you should parameterize is connection/authentication. Moving the whole object to parameters allow you to still store the authentication key in appsettings, but most importantly, allow you to replace the whole authentication type between local and cloud, as in the cloud, the value should be set to manage identity.




Original value


   "scheme": "Key",

   "parameter": "@appsetting('<connectionname>-RawAuthKey')",

   "type": "Raw"


New Value



Make sure that you include the following new parameter:


"<connectionname>-auth": { "type": "Object", "value": { "scheme": "Key", "parameter": "@appsetting('<connectionname>-RawAuthKey')", "type": "Raw" } }


When deploying to the cloud, the logic apps that will host this code should be given permission to access the connection via its managed identity, and this parameter should change to indicate managed identity as the authentication scheme:


"<connectionname>-Auth": { "type": "Object", "value": { "type": "ManagedServiceIdentity" } }


This change in the authentication type is important for cloud deployments, as Raw authentication keys are only valid for 7 days. Locally, the designer in VS Code renews the raw authentication token every time that the logic app is saved. This behavior doesn't happen in the cloud, as connections created in the cloud take advantage of the managed identity. Also, notice that if a connection deployed to the cloud via ARM template, the template should also allow the logic app managed identity to access that connection.

After all the changes, your connection should look like this:


"azurequeues": { "api": { "id": "/subscriptions/@{appsetting('WORKFLOWS_SUBSCRIPTION_ID')}/providers/Microsoft.Web/locations/@{appsetting('WORKFLOWS_LOCATION_NAME')}/managedApis/azurequeues" }, "connection": { "id": "/subscriptions/@{appsetting('WORKFLOWS_SUBSCRIPTION_ID')}/resourcegroups/@{appsetting('WORKFLOWS_RESOURCE_GROUP_NAME')}/providers/Microsoft.Web/connections/azurequeues-1" }, "authentication": "@parameters('sql-std-Auth')", "connectionRuntimeUrl": "@parameters('sql-std-RuntimeUrl')" }


Your parameters file should include the following parameters:


"azurequeues-RuntimeUrl": { "type": "String", "value": "https:// ****************.**********************************" }, " azurequeues-Auth": { "type": "Object", "value": { "scheme": "Key", "parameter": "@appsetting('azurequeues-RawAuthKey')", "type": "Raw" }


Once those changes are made, both runtime and designer will be able to parse the connections, and the connection.json file doesn’t need to change between environments, even if you have a different connection across each environment.

Parameters.json might still need changes when deploying across environments, since you should change the authentication type and the connectionRuntimeUrl.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.