Power Automate - Building Readable Flows

They say the best code is written in a way that you don't need to add comments, just good naming and design, and that had me thinking about Power Automate.

Power Automate is a literal flow chart, flow charts were created to make processes easier to read. So why can't I understand what the hell some flows do!

And that's what this blog is all about, how with a few small changes you can build your flows in a way that anyone can open and understand 😎

1. Planning
2. Naming
3. Notes
4. Design

1. Planning

This one is kind of obvious but still very important. The biggest reason flows become hard to read is lack of planning. If the developer takes a "figure it out as i go", then the end result is disjointed and confusing.

So for every flow you should plan out a couple of key things:

• What's the start state of the flow
• What's the end state of the flow
• What pieces of value happen within the flow

I recommend a lot more planning personally (Power Automate - 4 Steps to Building a Flow), but if you have these basic ones it will really help make the flow structured and consistent.

2. Naming

Naming things right will have probably the biggest impact on the readability of your flow, there are 2 golden rules:

1. Describe in clear language (no abbreviations)
2. Be consistent

I have 2 patterns I follow:

Variables

Variables need to clearly explain what data they are going to hold and the type of variable.

Actions

Actions have an additional requirement, what action it is. As all actions share the same connector image, if you remove the action type it can be really hard to read.

As example, how easy is it to read the below flow, how about can you tell me what the 2 actions do?

Guess what i do is create item, Guess what i do2 is delete item, quite a lot to get wrong lol

So actions must keep the original name of what they do. How much easier is below to read.

Again with consistency, all mine are Action - description. I also ensure the description is detailed enough. I could just put Get Items - records, but by adding the filter query of over 10 days old I can get a lot better understanding of what the flow is trying to do.

3. Notes

Yes I know my first sentence made out that you dont need notes when you create clear solutions, but its not true. Notes are such an under utilized feature in Power Automate. You don't need them everywhere, but there are a couple of times they can be really useful.

Expressions

If you have one of those beautiful expressions that use multiple functions to come up with an amazing solution (you know the ones 😎), without the developers insight and understanding these can be incredibly hard to understand let alone edit. Dropping in a comment that explains what the expression does and can make everything make sense (including for future you who has forgotten what the flow does too).

Solutions Through Pain

Again another one that we all experience. When something that should work just doesn't and you have no idea why (lets be honest its normally Power Automates fault but anyway). Through blood, swet, tears, repeated trial and error you come up with a solution. This where a note is so important, not only does it explain what its doing, but it also explains why the expected way doesn't. I've done it before where I refractored a flow, thought the original developer was mad and rebuilt the "right way", only to find it didn't work. I then had to suffer the same pain as the original developer to get it working again.

4. Design

Design is the probably the most difficult to nail, as it's more of interition. But there are a couple of key call outs that good design should have to make the flow easy to read.

Keep It Short

This is kind of obvious but often the most common not done. Keeping your flows short makes understanding your flow so much easier. And there are 2 main ways to do this.

The obvious is to use less actions, and this can be done by:

• Removing unnecessary actions like variables and composes
• Using right actions like filters instead of conditions
• Ordering your actions before and after branches

The last one is probably the most under utilised but can add make a flow so much easier to understand.
If you duplicate actions in branches it easy to think they could be very different paths, but if they are the same except for inputs, then moving to after the branch and using a coalesce() ensures everyone understands its the same.

The other way is to split the flow into childflows. That way we make the actions more relatable. Though this can only be done when the actions are related and/or complete a specific piece of value. This rolls in nicely to the next design principle...

Grouping Actions

Actions that are directly related or complete a specific task should be grouped together. When you create your flow don't think of it as one flow full of actions, think of it as stages, and each stage should have actions. This design principle has 4 levels:

1. Ensure related actions are next to each other
2. Name the actions in a related way
3. Add the actions into a scope
4. Move the actions to a childflow

The scope is the most common used but in my opinion should be the least used. It adds nesting (see later), and api calls, and in most cases naming in related way is just as good.

Simple Paths

And this is the big one, you need to keep your paths simple, and the 2 biggest impacts to flow paths are:

• Branching
• Nesting

Adding branches means that you are now trying to understand each decision on its own, losing focus on the overarching point of the flow. It also forces duplication of actions which again can mislead the developer in to thinking its differences are bigger.

Nesting is similar, with how Power Automate is displayed it is easy to lose what level you are in and the impact of each of those containers.

Understanding what each of those nesting boxes means and how it impacts values can be incredibly difficult.

I strongly recommend you check out my previous blog about 'The Direct Methodology' which deep dives into how the other benefits of simple paths and techniques to enable it.

Think Like a Human

I see far to many flows that follow a very unnatural process path. I'm not saying you should copy the human process, but you need to follow the same logical steps a human would. My best example for this is handling 2 different outcomes in a loop.

Nearly everyone would make a flow like this:

You loop over every interview form, if passed then send passed, if failed then send rejected. But is this how you would do it in real life? I suspect you would sort into 2 piles by pass and fail. Then work through the passed, then work through the failed.

• Easier to read ✅
• Easier to read logs (i can find nth passed so much easier) ✅
• Uses less api calls so maybe a ✅

If you make your process follow those human 'common sense' steps, then it is instinctively easier to understand.

As you can see there are some simple steps that add little development time that can make your flows so much easier to read, and trust me, future you will be so happy when debugging a critical issue 😎

 
😎 Subscribe to David Wyatt