Logic Apps Parameters vs ARM Parameters

I got the question about what the difference is between ARM template parameters and Logic App parameters and when these should be used, so that is what I’ll try to explain in this post.

First of ARM template paramters are used with ARM templates and the ARM template is used when deploying ARM based resources to Azure and Logic App’s is a resource that is deployed via ARM templates.
The workflow definition language behind Logic App’s is very similar to ARM templates and therefore it can be tricky to see the difference in the beginning.

ARM Template Parameters

An ARM template with a empty Logic App looks as following, two ARM template parameters logicAppName and logicAppLocation and one resource of type Microsoft.Logic/workflow inside the Microsoft.Logic/workflow the Logic App Parmeters are found in the parameters object.

In the Designer View it’s pretty evaluated and easy to read for operations.

ARM Template Variables

This is almost an unkown feature and often used to little.
This is where we can evaluate expressions for later use, so this is really practical when we want to add two parameter values or use some functions to generate the value that shall be consistent over the Logic App.

In order to prove how this works we will concat two parameters, this could be used for creating resource links etc.
The simpel logic app will just contain a response action with a body value of the evaluated concatenated value of the parameters.

The variable can be found after the parameters in the ARM template:

}
},
"variables": {
},
"resources": [

When adding a variable we can the access parameters as input to the evaluation, this makes it possible to combine two paramters with the concat function and it will look like this:

The variables will be evaluated during deployment just as the ARM template paramters. This means that when deployed the value will be displayed as text, so if logicAppName was set to INT001-Example and the flowname was set to Orders the evaluated result of the concat function would be: INT001-Example-Orders. And when looking at the deployed Logic App it will look like this:

Logic App Parameters

The Logic App paremeters are found in this section under “parameters”. Containing a parameter “url”.

The Logic App parameters have a diffrent syntax: @parameters(‘laparam’) and when accessing arm parameter with name url it would look like:

"uri": "@parameters('url')"

These parameters are evaluated at runtime wich means that this is not changed after deployment or in the designer so even after deploy or first run is done it will always look like this, but during runtime it will be picking the value behind the parameter:
The result would look like this after deloyment:
Code View

“uri”: “@parameters(‘url’)”

Desginer View

But during rumtime it will evalve and if we check a run it will look like this:

Summary

It’s good to know when and why to use diffrent types of parameters, I’ve seen alot of over use of Logic App parameters and I just want to share the knowledge and spread how these are treated.
We want to push the static values to ARM template parameters so that it’s easy to see the values during a check if the Logic App in the designer to verify that everything is ok, since Logic App paramters will “hide” the value in Code View. It also makes it easy to switch values between DEV/TEST/PROD environments since there is often change between environments. Also make sure to use ARM template variables whenever you need to reuse a computed result over you Logic App.

But with that said when using reference objects for translation or lookups Logic App Paramters is the obvious choice since it’s easy to access. We have seen this succesfully and easy to use when keys are sent in the inpiut data and the used in lookups i.e. @{parameters(‘myobjectparam’)[triggerbody()[‘key’]]}

So make sure to use the appropiate type at the correct time and I hope you got some more insight in how/when and where to use these 3 diffrent types.