Naming convention for Power Automate

I am more than willing to expose all the mistakes I made when I started my journey as a citizen developer – but only to help others to learn from them! One of my biggest mistakes was not using any kind of naming convention. I simply didn’t even realize such thing exists.

But why was it such a mistake? A name is just a name? Or is it?

What is a naming convention?

A naming convention is simply a set of rules for naming things. There are different naming conventions, even for Power Automate and Power Apps, but in my opinion… the only thing that truly matters is that one exists and that it’s consistent. I don’t waste time fighting over preferences.

Why having a naming convention matters?

While I love writing technical documentations, I have learned that most of the so called normal people don’t particularly enjoy this activity. When you follow a good naming convention, your flows become self-documented and usually no additional documentation is needed.

While it might be obvious to you now what your flow does and how it works… try again in six months. Or after a full year or two. I don’t even dare to say how much time I have wasted trying to figure out my own flows. It’s a pleasure to open your own flows after a long time and immediately get a hang of things. Having a naming convention helps with future development and troubleshooting.

But it doesn’t end there! It also helps others in the future if they have to pick up your flows. The on-boarding will be much smoother if the flow is well organized.

Easy naming convention for Power Automate

Disclaimer: This is my preferred naming convention, and it’s also quite common among other Forward Forever team members as well. But it’s not by any means the one and only naming convention. Feel free to adjust according to your own preferences.

Flow names

Let’s start with the big picture; naming the flow itself. If the process contains multiple flows, I make sure to give them clear and concise names. I usually always include an order number to the flow name if the flows follow each other in some manner.

Here is my usual formula:
Name of the flow – Order number  – Project name

Obviously the order number is only relevant if there are multiple flows that follow each other. If there is only one flow or the flows don’t follow each other in any spesific order, it can be omitted.

Action names

I always keep the original action name but add my own definition as well. While I am familiar with most of the actions, the person next to me might not. It makes their job must more easier if they can immediately see which action I’ve used without having to guess. 

Here is my usual formula:
Action name | More detailed action name

Notes also serve a purpose. Many people like adding their expressions as notes (to avoid having to click them open). Or sometimes you need to explain yourself a bit, which is okay as well.

Scopes

Scopes are an easy way to organize your actions to logical steps. It makes the process more visual and clear. I highly recommend using them. Because they are mostly used for grouping, I don’t bother to keep the original action name, but that is just my preference.

Here is my usual formula:
Short and descriptive name for the group of actions

Variables

Lastly, naming variables. The main reason why I name my variables this way is to keep them consistent with my Power Apps naming convention. But it also makes variable stand out in expressions.

Here is my usual formula:
var + short descriptive name in camel case

Be consistent with your naming convention

Whatever naming convention you end up adopting, be consistent with it and use it as you build your flows. If you try to implement a naming convention as an afterthought, it can be a surprisingly tedious job. The best way is to make a habit out of it; when you get used to it, it becomes second nature.