DEV Community

Cover image for Power Automate- When to & not to use Variables
david wyatt
david wyatt

Posted on • Updated on

Power Automate- When to & not to use Variables

Image description

I spoke in one of my previous blogs how citizen developers starting in Power Automate often use the Compose action far to often. But when a more experienced, pro dev starts in Power Automate they often have a different problem, and that's variables. With code everything generally runs through variables, so pro devs often take that approach to Power Automate. Yet Power Automate in reality very rarely needs variables. Variables can make the flow easier to read and understand, but too many can do the opposite. Additionally they use up Power Platform API calls, so in high volume flows the limit could be hit, causing throttling to the flow.

Image descriptionYes this is what one of my very first flows looked like!

There are times when variables should be used, but not as often as you may think.


Loops

This is the only real reason to have variables. During loops we might need to append or increment variables. Additionally we might set a boolean or a value to flag if atleast one item meets a condition.
If you look at the variable actions:

  • Append
  • Increment
  • Decrement
  • Set

all have primary use cases inside loops.

Image description


Now there are a couple of reasons that they can be used in exceptions, these are:

To Simplify

This one is quite a shade of grey, as really adding additional steps doesn't simplify the process. But in some cases, particularly if a value is repeatedly used, a variable can be useful. Ensuring the parameter can be find quickly at the top of the Dynamic content window definitely has its benefits. Additionally if its an expression that might get updated in future, updating it in a variable set is a lot easier then searching through every action to find and update.

Config Variables

Having hardcoded values within a flow can be a nightmare to find if it needs updating, storing it in a variable at the top of the flow makes sense.

A good example would be a flow that grabs the last 7 days, hard coding the 7 in the expression is the optimum way to do it. But having the ability to change the timespan to say the last 28 days by updating the first action, gives the flow more future proofing.

Though there is the elephant in the room for config variables, and that is environment variables. All config variables should really be stored in environment variables, as not only is it a lot easier to update, but can be environment specific.

Image description


So when shouldn't we use a variable:

In a condition

A condition action should be used to run actions, not to set a variable, as an if expression could easily be used instead (with the only exception being very complex conditions, where a condition action might be simpler to read and maintain).

Image descriptionTrying to replicate this in an expression is possible, but maybe not worth the effort

To Hold an action parameter

Variables sit at the top of the Dynamic content window, so it can be tempting to pass outputs into a variable. Not only does make the process more complex, it uses a minimum of 2 additional api calls.

To Hold an Expression

Sometimes it's tempting to add a variable to hold the output of an expression, but with everything in Power Automate a global variable, there is no need to add the additional step. Simply pass the expression directly into where the variable is used.

Timestamp

I often see utcNow() in a variable for a reusable timestamp (example for appending to file names to easily batch). But as part of all trigger outputs a timestamp should be provided.


Variables are key to coding, and key to Power Automate, but just not quite as key, and aren't always as necessary as we think.

Top comments (0)