Power Automate Best practices - Flow Naming Convention

For the last year and a half, I have frequently talked about Power Automate Best practices, Tips and Tricks on several community online events. You can see some of them here:

And now that I’m preparing a new set of Best practices, Tips and Tricks, I thought it would be nice to publish them individually, adding more details.

Unlike some of my colleagues who initially addressed more technical topics about Power Apps in their list of best practices, I think everyone who starts working, or is already working, on Power Automate should respect the most essential best practice: naming convention. So, my first Best practices, Tips and Tricks couldn’t be any other subject than this topic.

#1 Flow Naming Convention

Later on, in other Best practices, Tips and Tricks, I’m going to address other types of naming conventions but to start I like to address the name you give to your business flows and the importance of having a proper naming convention.

Flow Naming Convention

Basic rules about Flow names:

Power Automate allows you to set a flow name between a minimum of 3 and a maximum of 254 characters!
You can use all types of characters

So you can actually set a proper name to define your flows. And the main reasons you should provide a descriptive and good name to your flows are:

It improves readability.
- By setting a proper name, you can easily identify what that flow is intended to use for, without the need to enter the flow design and try to figure it out. So, you not only provide readability but you also save future time (not spending time looking for your flows) and frustrations. You may think that this is not important, you have created the flow, you know what is intended to but trust me after 3 months you will completely forget it!
It also transfers knowledge between your team or organization.
- Sometimes Flows are shared by a team, or you are a consultant that is creating flows to your client. They also need to be aware of them, they also need to understand them. You may leave the project or the company in the future, and they will need to continue the work or make future changes. Having a proper naming convention and providing a good descriptive name is auto-documenting your processes.

I bet if you work on a software house and create a C# project like this:



using System;

namespace mynamespace { public class Class { void function1(ref string parm1) { /* * Implement the logic * */ } } }

you will be fired immediately, so why do the same on Power Automate?

In the picture below on the left side, you see some examples I have on my personal Power Automate environment:

Power Automate Best practices

If I need to do a critical analysis or a good practice assessment to my environment I probably get to the conclusion that:

The first four flows need to be reviewed immediately.
The fifth flow is actually ok – I know that this is a flow to handle Power BI meetup feedbacks
Nevertheless, I’m not saying that it could be improved to have an even better name.
And the last three flows, despite that are more or less readable it could be significantly improved.

And as you see I also have:

a mix of Portuguese and English;
some with _ order with spaces
some in Pascal case – programming naming convention that uses a single uppercase letter for each additional word making it easier to read code and discern the purpose of variables – and others in plain text (normal writing)

Also in the picture, on the right, I’m providing a simple naming convention structure. Make note that I’m not saying that this is the best naming convention and you should follow! If there is one thing that I learn in all these years as a consultant is that each client has its own naming convention and we need to adapt to them, of course, you can and should always suggest improvements and change if it makes sense.

The important is to define a good naming convention for the names of your flows and implement them across all your flows. In my example, I use/suggest:

<client-name> – <context> – <description>

For example:

DVS is a short term for my company name – DevScope
TimeReport App is the name of the Power App that is using that flows – It is in Pascal case here because is the name of the app “TimeReport”
“Create Time Report” or “Get Budgets by Project” these are the description of what this flow is doing.

Again, you have a maximum of 256 characters to define the name of your flows. Take advantage of that to internally implement best practices and rules to define the name of your flows.

To finalize, you can always go back to your existing Flows and fix the names of all of them safely because it will not break anything. The app or systems that are invoking or interacting with that flow will not be affected by these changes. For that, you just need to: