The question is Variables or Compose actions in Power Automate?
Variables
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.
Compose
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
outputs('Compose')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.
Performance
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.
Parse JSON sounds far too complicated to have to mess with.
It isn’t really that complicated. It’s like anything new once you figured out how to do things it will become easy.
It all depends on if performance and manageability of flows are important or if a flow only needs to work. I see a lot of slow flows that take hours and hours while they could do the same job in a matter of minutes or seconds.
The same arguments also apply for licensing. If you run too many steps you could reduce licence costs by going the more advanced route.
For some reason, when I select “Reply” to your reply, it does not give me a box to enter my reply. My only option is to Cancel Reply.
I wanted to respond to your “It isn’t really that complicated” comment. It seems I would have to define all the “variables” in the Content box at the top half of Parse JSON, then define all the matching Schema on the bottom half, getting all the formatting correct, for dozens of variables and keep everything in sync whenever I add or change variables, and do more Parse JSON whenever I want to manipulate them.
My flows have lots of variables but do not take hours and hours to run. They take seconds and minutes. Even with the concurrency set to 1 to avoid any issues. I do not have any licensing issues either.
Interesting. I like this idea. I have two comments. The first, which I think this addresses nicely is concurrency. You do not want to use variables inside a concurrent loop as you will find random results if those are set in a concurrent loop as the values are global to the flow.
Second, I use a technique, I don’t remember if copied from you, where I have a HTTP activated flow which just returns a JSON with a list of constants my application uses, and then every flow in the application calls this at the start to get all the constant values for that application, allowing us to easily modify and test without having to modify each separate flow and also the advantage of defining and seeing all constants in one place.
For global constants shared between everything in your solution, you can create Environment Variables for that (Open your solution > New > More > Environment Variable).
Another difference between compose and Parse JSON is the schema, in the JSON you have to identify the type of each variable in the schema; You can make everything a string for simplicity, but then you still have the complication around having to escape characters, which isn’t an issue with compose.
Hi Ariel,
Yes, all of the options have their advantages and disadvantages.
Lot of Complications… i am still learning 🙂
So, I have been using a couple variables in a flow here and there without issue, but I have one with 24 variables. Most of those are strings, but there are a couple integers and one array as well. I was looking for an option where I could initialize all of these variables in a single action. In an attempt to clean my flow up, I tried throwing them all into a compose, but that doesn’t work.
Ideally, I could initialize the variable’s name and type then set the value later but I haven’t gotten this to work with the Parse JSON action.
Any other ideas?
Hi Aaron,
It all depends a bit, if these variables are actually constants then I would consider using a select action. for each ‘variable’ create a mapping and then set the value.
Hey, that’s brilliant!
I have a XLS query that results in one row, so I set the content as outputs(‘List_rows_present_in_a_tabl’)?[‘body/value’]?[0].
Then simple paste in one row of sample data from the XLS as the JSON sample, viola!!
An easy object to access the fields. Previously had to drudge though and write an expression for each, was a pain, and harder for someone else to edit.
outputs(‘List_rows_present_in_a_table_Config’)?[‘body/value’]?[0]?[‘Column Name’], since, edit, repeat…
This is WAY simpler!
Thank you for your comment. There are sometimes multiple ways of doing things. Some are easier and some are faster.
Thank you for the insights on using JSON as a means of creating constant values that can be used throughout the workflow. This will help be to pair down the use or variables quite considerably as so many end up being nothing more than point in constants. I also like that I can create one JSON for many constants and put it in a scope. This will help me tighten up my flow action coding and eliminate all the work around creating endless variable actions.
I have found you can use Compose in the same way, in that you can compose a multiline JSON object, just like in the Parse JSON action, but you don’t need a schema. Likewise, when you refer to the fields of that composed object using “outputs(‘compose’)?[‘MyField’]”. It will display as “Outputs”, but later when you reload the Flow, it will display as “MyField”
I’m also toying with the idea of copying an object into a variable, then using the “setProperties” function to update the fields in the variable (by passing it through a Compose), without having to use a bunch of separate variables for each field that might change.
In general variables are ok, but don’t use them in apply to each as that will stop concurrency features from working.