What Not to do in Power Automate
Tags: powerautomate, powerplatform, lowcode, rpa
Published: 2023-11-20 07:14:02

There are loads of great blogs sharing what to do to be a great Power Automate developer. But that made me think, I've never seen any on what not to do, so I thought I would share my top 10 things not to do in Power Automate.

> Before I start, this is my opinion so don't take it personal if you do do these (in fact if you do you could take it as a complement, I've been known to be wrong a lot in the past 😎).

I've grouped them into 3 levels: Basic, Advanced, Master, with it getting more controversial as go up the levels.

## Basic

**Set variable with condition**
Hopefully no one disagrees with this one, but we should very very very rarely be setting a variable with a condition action (the only time I could think of is if the condition was incredibly complex, but in that case there are bigger issues in the data format).

A simple if() expression as the input should be used instead. I would also add in if a variable should be used at all.

![condition](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bm7zmvd31l59cnedyx3o.png)

**Filter after get items**
Another no brainer, get items has the filter query which should be used instead (unless its a on a non delegatable query like null results in SharePoint).

![filter query](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s4j85xeonatqk7ku0jl7.png)

This one has some big negatives too, it's a massive waste of Power Platform API calls and can lead to incorrect data (if pagination isn't setup right).

**Condition after trigger terminating flow**
Just like 'Filter after get items' this is another no brainer, we should not be running the flow just to terminate it. The flow trigger condition will stop the flow from even running. This again saves Power Platform API calls and keeps your flow logs a lot tidier and easy to read.

![condition trigger](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t54w7lwd0p6gej5dsbzt.png)

**Use of Compose**
This is kind of my 'red flag to a bull' design in a flow (I've even done a whole blog on it, [Using Compose the Right way](https://dev.to/wyattdave/power-automate-using-compose-the-right-way-4o14)). Composes are misused all of the time in Power Automate, there are a few niche cases where they are useful, and they can be good for debugging your code, like a console.log(). But they should not be in your production code, they waste API calls, clutter your variable list and just generally annoy me.

**Rename without action name** 
Naming conventions are key to good code, and the same is with Power Automate. Having no naming convention could be a point on its own, but hopefully that's too obvious. But one mistake I see is when people have a naming convention, but they totally rename the action.

Why is this bad, well it makes reading the flow so much harder. Most actions have the icon based on the connection, so every SharePoint action looks the same.

![action naming](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c145w8guxi74dcu0ts90.png)

This means I have to open the action to understand which action it is, this is a big pain when trying to debug or do a code review.

## Advanced

**Loop for one item**
I see this a lot (and I almost put this in the basic group). Because Power Automate tries to help, everytime you put a key/field from an array into an action it drops that action into a loop. 

Now I know Microsoft is just trying to help, and it is useful, but it also means that when we filter an array expecting just one result it gets put into a loop. This loop action is not only pointless and wasteful, it means sometimes a variable has to be used.

But there is a simple solution, the first() expression, or my prefered array position (where we add [0] to our array expression).

![first from array](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ptzfsyht1siqrzarbff3.png)

**Multi variables instead of object**
Often we don't even need a variable, but if we do for something like config, we should not be having multiple (say more than 3).
Instead we should be using one object variable, it means a little more coding the expression because we have to add the key to the variable.

![multi var](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0ix9uxhgp89r2sxvj7yc.png)

Or you could just use a Parse JSON to make it easy.

You can even update them with the setProperty expression.

![set property expression](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4x6jo0pzwsc4kckbao32.png)

**Not using coalesce** 
Coalesce is our friend if we want our flow to be kept simple and efficient, so when its not used it means the flow hasn't been designed right. What do I mean, well coalesce allows you to pass in multiple inputs and it uses the one that is not null. So we should be using this in branching, we then use the coalesce to unify all the possible branches back into one.

![coalesce ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9ybror0rrhdezqpq0kkv.png)

## Advanced
**Condition in loop**
You should never need to put a condition as the first action in a loop. Especially if it only has an action in one branch (single branch condition).

It's very wasteful to pull all the items into the flow, then check each one. What we should be doing is using the action query filter, or a straight filter action if the filtering happens after the get items.

That is not so controversial, but what is is that I think you should have the same rule even if you have an action on both conditions. So I would filter by true, loop over those items. Then do a filter for false and loop over those separately. This may sound a little pedantic and pointless, but:

- The flow runs a little quicker that way
- Drives consistency with single branch conditions
- Easier to read logs for debugging as each part of the process is separated.

![condition filters ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t1ye0lqjlk2aenh3b79t.png)

Think of it from a logical way, if you were sending out accepted and rejected letters, would you:

- Go through the pile, and process each with accepted or rejected

Or

- Sort into accepted and rejected piles, then process all the accepted, then all the rejected

**Condition branching**
This one is kind of similar to 'Condition in loop', we should not be using conditions as branching. Conditions should always merge back into one branch, there are a couple of benefits:

- More efficient (no duplication of actions across branches)
- Easier to maintain (update one action instead of 2)
- Easier to read the flow
- More stable in development (nesting can impact/slow down the browser and make development harder)

If you want to know more about this overarching approach check out my full blog on it [Power Automate, The Direct Methodology](https://dev.to/wyattdave/power-automate-the-direct-methodology-32mf)

---

I'm sure there will be disagreements with my selection and ones I missed, so feel free to add to the comments.