With most Power Automate Developers starting as Citizen developers it is very natural to use actions/connectors in a way they weren't supposed to. And out of all of them I see Compose the most.
The Compose is the most misused action in Power Automate
When I first started using Power Automate, I loved Compose, it made my development quick and readable, and kept my flow more efficient by removing the initialize of a variable. But on my return to those flows later I suddenly realised they weren't as readable.
It reminded me of my VBA development days, whenever I would borrow 😏 code from Stack Overflow it often wouldn't work, then I realised it was the Option Explicit tag at the top of the macro.
Option Explicit enforced variable creation and type (Strongly Typed), which as a self taught developer I thought of as burden rather than a benefit. Yet over time I started to see the benefits:
- Returning to the macro was a lot easier as I could see all the variables and types in one place
- Typos were caught instead of making new variables
- I planned my code a lot better, instead of randomly adding variables
And this is how I have started to feel about Composes
- When used they are less planned and more reactive
- They are a lot harder to use compared to variables
- You can't set the type
- In most case they aren't more efficient, and are used wrong
So let me explain.
Less Planned
This is very much inline with VBA, when I'm working in Power Automate it is sometimes easy just to go with the flow (sorry for the pun) and not plan. In these cases you often drop a Compose in as you haven't planned for a variable. This means you often end up with duplication and confusion when looking back. Trying to understand someone else's flow is hard enough, but when the developer didn't even know what they were creating, it's even harder.
Hard To Read
If you look at the image below you will see what I mean by, hard to read:
Most actions use descriptive and relatable names, but not Compose. Everyone is tagged as Output, which wouldn't be the end of the world but it means you can't search for them easily.
On top of that variables are not only named better, but they are also conveniently blocked together at the top of the Dynamic Content list.
No Defined Type
Not being incontrol of the type introduces lots of unknowns, and this is the last thing you want in RPA. If your action is expecting a string and the Compose decides on a integer, it can easily break your flow. Debugging this when its a single input hidden in 1000s rows of data can be a knightmare. There are lots more benefits to Strongly Type languages, check out here if you want to read more https://dhh.dk/arc/000074.html.
Used Incorrectly
And this is the big one, in most cases Composes are not needed and a total waste (Less optimized rather then more).
I get the logic, that a Variable requires 2 actions (Initialize and Set), where Compose requires just one. But just because it's more efficient doesn't make it efficient.
So a good example I often see is something like this:
The developer is using the Compose to calculate the email address and passing it to the Outlook connector. It is definitely better than using a variable.
But the question is what value does the Compose add? Every input into Power Automate is Global, so we can call it anywhere. This means whatever we pass into a Compose, could be passed directly into the Connector.
So we are at the point where in most cases using a Compose makes your flow harder to read and less efficient.
So why does Compose exist, because it does have some good use cases.
In Development
Reading a the state of a variable/input is hard in Power Automate (would it have killed you to show the inputs in the Condition Action Microsoft!!). So dropping Composes in during development is really useful (a Console.log or Debug Print). But these should always be removed in production.
In Loops
There are significant performance gains to using Composes inside loops to avoid loops within loops (See my previous blog here for more dev.to/wyattdave/top-5-ways-to-optimize-your-flows. Though most times I would recommend a Select instead of a Compose).
Updating Variable with itself
You can't reference a variable within itself like most languages e.g iNum=iNum+1. That's why we have increment and other basic actions
But there a couple of cases where the action is missing, the one I use the most is Union, as if I wanted to append an array to an existing array I would have to pass it to another variable and pass it back. In this case a compose seems like an easier way to union the arrays and then pass back to the array variable.
I know there are plenty of other uses for Compose, and I'm glad Microsoft created it, just make sure you use it right, and remember in most flows you shouldn't need it.
Oldest comments (0)