Tags :  

Power Automate Best practices, Tips and Tricks: #1 Flow Naming Convention

Last updated on: September 24, 2021

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:

  • Access you Power Automate environment;
  • Edit the Flow you want by pressing the edit button of the list of your flows

Edit the Flow

  • Give a proper name and click Save.

Power Automate Best practices

Stay tuned for the next developer approach Power Automate Best practices, Tips and Tricks.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.