The question is Variables or Compose actions in Power Automate?
Table of Contents
Sometimes you need a place to put things. To explain the idea of variables I often use the idea of drawers. You can put things in them and you can take things out, then you can put different things in them and take them out too.
In Power Automate we have these kind of drawers too. Like in many other programming languages, Power automate calls these drawers variables.
The general process is that you first Initialize a variable and then you can use that variable throughout your flow.
The initialize variable action asks you for a name of the variable and the type of variable and an initial value.
You could compare this a bit with buying some drawers and then putting drawer liner in to make the drawer suitable for whatever you want to use your drawer for. Different types of content may need different drawer liner.
This variable type in Power Automate is quite important, as it will restrict the use of your variable.
Once a variable has been initialized you can use the set variable to change the value of the variable.
The compose action is different. The compose action is like taking a photo. Once you took the shot it is there. You can look at it but you can’t change it!
In flow you have the compose action that you can add to a flow and using dynamic content or expressions you can set this to anything you like
Then in any future action you can use this following expression
Or you can use the dynamic content to select the value of your compose action.
Note that you don’t need to initialize the compose with a type, but also you cannot change the value of the compose once it has been set.
For some more advanced uses of the compose please have a look at the advanced Pieter’s method post that I wrote a while back.
Variables or Compose
First the obvious reasons for using Variables or Compose actions will depend on if you need to change the value of the data that you want to store in variable or compose.
But don’t straightaway jump onto variables just because a value changes. If for example you were to set a variable multiple times in a flow, could you consider using compose actions and just reference those compose actions instead? Quite often you might find that the option is there.
The other reason we have see so far is the type casting. Do we want that restriction of the types ( variables) or do we prefer the un-formatted data stores of compose
on of the disadvantages of compose actions is that when you use the compose actions you will see just a label with Outputs. As you get more compose actions it becomes quite quickly painful as you can’t see which compose action was referenced. Hovering over the label will give you the clue but that is still not very friendly.
The other negative of variables is that you end up with many initialize actions at the beginning of your flow, cluttering the flow.
Parse Json instead
Now, there is a 3rd option instead of variables or compose. The parse json action can work like compose actions and additionally it gives you the option to combine multiple compose actions.
The parse json action you could configure like this, where you supply all the values that you would put in separate compose actions
So like this you could use just one Parse JSON action to replace many compose actions. As as you run the flow you will find Setting1 and Date1 appear in the output.
The additional benefit is now that as you reference the data you will see Setting1 as a label rather than outputs as we saw with the compose action.
Then there is still an additional reasons to use a parse json or a compose above variables and that is performance. Variables will slow down your flows. When you have multiple branches running, either parallel branches or Apply to each actions with a concurrency higher than 1, then you will find that variables used within the branches will lock your branches.
Using Compose actions or Parse Json actions will avoid this slowing down of flows.
Then additionally the reduction in steps will also help you to stay within the limitations of non-premium licences.