Table of Contents
• Why Use Power Automate Naming Conventions?
• Flow Names
• Action Names
• Trigger Names
• Variable Names
• Connection Reference Names
Why Use Power Automate Naming Conventions?
A consistent naming pattern makes it easier for other developers to understand what a flow does without having to review the details of every individual action. Cleanliness of the Power Automate code speeds up work and reduces bugs.
Flow Names
A flow name should begin with a verb (action word), describe what outcome the flow will achieve and include the trigger type. Use proper case. Be as concise as possible.
| Good Examples | Bad Examples | Bad Reason |
| Send Daily Status Report (Scheduled) | Send Daily Status Report | No trigger type at end of name |
| Get Currency Rates From Web (Automated) | Currency Rates From Web | No verb at beginning of name |
| Change App Ownership (Instant) | Change app ownership (Instant) | Not proper case |
Prefix the flow with a group name at the start when it is part of a set of related flows. Do this to communicate the relationship between flows. Not every flow built requires a group name. If a flow does not belong to a set then do not add a group name.
| Examples With Group Name |
| Generate Contract: Create & Send PDF Contract (Automated) |
| Generate Contract: Calculate Line Item Prices (Instant) |
| Generate Contract: Assemble Terms & Conditions (Instant) |
Action Names
A flow action name must always start with the action’s original description. It is important to include this so developers can understand which action was selected without having to expand it. Then add more details about what the action is doing within the context of the current flow.
Use proper case. Separate the action name and its context using a colon.
| Good Examples | Bad Examples | Bad Reason |
| Get Items: Inspections Table | Download Items From The Inspections Table | Original SharePoint connector action name missing |
| Compose: Email message body | Compose | Missing description |
| Send Email (V2): Daily Report To Operations Leadership | Send Email (V2) – Daily Report To Operations Leadership | Used a dash instead of a colon |
Trigger Names
Automated flow trigger names should include the table or event name in the trigger name.
| Example |
| When An Item Is Created: Safety Incidents |
Scheduled flow trigger names must display the recurrence schedule.
| Example |
| Recurrence: On The 1st & 15th Of The Month At 5PM |
Instant flows trigger names should also describe the event that triggers them.
| Example |
| Manually Trigger A Flow: When An Admin Wants To Create A New SharePoint Team Site |
Power Apps flow trigger names should describe the event the app which triggers the flow to start.
| Example |
| Power Apps (V2): When The User Submits A New File To Upload |
Variable Names
A flow variable name should begin with a prefix of “v” and describe its subject/purpose in concise manner. Use camel case. with no spaces between each word. Be as concise as possible.
| Good Examples | Bad Examples | Bad Reason |
| vQuantityInBox | varQuantityInBox | Do not prefix with var |
| vEmployeeFullName | strEmployeeFullName | Prefix str to denote a string data type is not necessary |
| vIsPastDue | vispastdue | Use camel case |
Connection Reference Names
A connection reference name starts with a noun to describe the connection account. Then it is followed by the connection type, the solution name and a unique identifier. These are automatically added when building inside of a solution.
| Good Examples | Bad Examples | Bad Reason |
| SvcAcct-SharePoint CurrencyExchangeRates-ac3d5 | SharePoint CurrencyExchangeRates-ac3d5 | Missing noun at beginning |
| SvcAcct-Dataverse CurrencyExchangeRates-be005 | SvcAcct-Dataverse | No solution name or unique identifier found |
| SystemAlerts-Office 365 Outlook CurrencyExchangeRates-32a0c | DavidJohnson-Office 365 Outlook CurrencyExchangeRates-32a0c | Noun is not generic. |
Did You Enjoy This Article? 😺
Subscribe to get new Power Apps & Power Automate articles sent to your inbox each week for FREE
Questions?
If you have any questions or feedback about Power Automate Standards: Naming Conventions please leave a message in the comments section below. You can post using your email address and are not required to create an account to join the discussion.
Great article, as always! Was literally thinking today that I needed to be more consistent with with my naming conventions the more that I use Power Automate (which seems to be more each week). Very timely! Question: why “v” and specifically not using “var” before a variable? Just curious. Thanks for these great articles!
Andrew,
I settled on “v” because it was shorter than “var.” Believe me, I agonized over this decision but “v” was the right one for me. Either is fine in my books. Just as long as variables don’t start with “str”, “int”, etc.
Hey works for me! Just didn’t know if there was another reason. These are all great, I will be implementing these for myself and my clients.
Side note: might be time to add Power Automate to the header of your website!
“No Ads, No Fluff, Just Power Apps (and Automate) Stuff”
Personally I use var, because other words begin with v so typing var will only bring up my variables when typing
Thanks for sharing a valuable information ☺️
Mohammed,
You are welcome. I wonder what others will think of my suggestions!
Good article! An additional useful rule that I use is to use some abbreviation/code before the name of each power automate flow, depending on the solution, e.g. HR REQ – Send notification, HR REQ – Update list items. The initial phrase allows you to identify flow from one solution.
Maciej,
Looks like we had a similar idea to use groupings as a prefix. We both must be on the right track! 😊
Hi Matt. Thanks for another interesting article. Can you expand on the reasons why a ‘v’ prefix is useful and the type is not? In what circumstances is the variable action not obvious? Whereas the type is not implicitly specified in either formulae or a set action and must be manually cross referenced for certainty.
Thanks.
CJ,
I favor this argument for not including the data type in the variable name.
“You shouldn’t name your variables after their types for the same reason you wouldn’t name your pets “dog” or “cat.” The name of a variable should describe its contents, not the type of the contents.“
Link to full essay: https://dave.cheney.net/2019/01/29/you-shouldnt-name-your-variables-after-their-types-for-the-same-reason-you-wouldnt-name-your-pets-dog-or-cat
Most actions and expressions only accept one data type so it’s straightforward to determine while browsing code.
Moreover, I find including the data type often redundant and does not improve clarity if you have a good variable name in the first place.
Examples:
vIsItemInStock vs. boolIsItemInStock
vItemSellingPrice vs. floatItemSellingPrice
vItemDescription vs. strItemDescription
vItemsPurchased vs. arrayItensPurchased
Those are my humble opinions on the matter 🙂
I’ve followed all your naming conventions up to this point, but I just can’t do the var one. 🙂 I don’t find the “v” very valuable since the {x} icon makes it obvious. I suppose if you worked in the JSON editor, the prefix might help. In Power Apps it makes sense to delineate between local and global, so I’m happy to use a prefix.
I also like to include the data type in the name because you can’t quickly identify it just by looking at the collapsed node. So, I tend to name them something like “ProductArray” or “ProductString.” But, to each their own, I suppose–I think consistency is the key!
I also think it looks nice in a for loop title 😀
Jenny,
Thank you for sharing. It’s always easier to understand when an image is provided 🙂
Jenny,
I agree with your point on the “v” and the prefix “var.” No value at all. Perhaps I will remove it before I publish the full standards. We will see!
The fun part of writing a standard is I get to make the decision and hear people debate it. For the Power Apps standard, I changed my stance after hearing what others had to say.
We disagree on having the data type in the name but I know it’s popular to do. If you want to hear my argument against, you can look at my reply to Paul CJ in this article’s comments.
I feel it is a wrong comparison of pets and variables.. We can have more 20 variables (not pets and we can identify them visually not variables) , also we might be working on more than 10 flows and some one who is not an owner(or owner revising after 3 months) and try to debug and wants see the variable type and he has to go back and check for the definition to know the variable type.
Nice!
Just curious for your opinion: to keep track of the origin of referenced outcomes, I group branches inside a scope and prefix each action inside with a distinct section code (010, 020 etc.). In your view, not something to be achieved with naming convention?
Cheers, Marc
Marc,
I would have to see an image of your example to understand it. I’m not sure what the numbering system looks like (010, 020) so it’s hard to understand the value added.
Like this: this is ‘my’ solution to see in expressions where to look. For example length(body(‘020-Folder_Levels’)) gives me a clue where that particular action block is located.
Hi Matthew,
So you always create a new connection reference, for every new solution that you create?
What is the advantage over having a kind of “generic connection reference” (for every connection type/user) that you reuse in every solution?
Rudi,
The same connection references should not be included in multiple solutions. This makes removing them from the production environment much harder once they are deployed. Imagine having to remove 5 solutions to get rid of 1 connection reference. Yikes!
What do I do instead? I either:
1. Include the connection reference only once in my “base solution.” Base solution meaning the main solution that is most core to the apps & automations functionality. I do this why the main component of the environment is an app.
2. Put my set of connection references in their own solution. This is handy when the environment is mainly used for a set of automations.
Great questions.
I’m really interested to know other’s thoughts on naming actions.
I understand the usefulness of keeping the original action name then appending a further description however, I find this gets very messy and confusing where you have lots of the same actions (e.g. Get Items) when writing expressions where dynamic content can’t be selected.
I’ve been puzzling over this myself for some time and I’m yet to land on a perfect solution. At the moment, I’ve resolved to rename the actions as it’s usually fairly obvious from the action what has been used, but this does require someone to expand the action to see it.
Hi Olivier,
It is possible to check what the action actually is by clicking the ( ? ) button to view the Help sidebar for that action, thus it is unnecessary to keep the original name of the action 🙂
I love the ideas with naming the flow. I’m going to steal that. The other thing I do with flow names is a suffix DEV or PROD.
Wow! A very good article. Thank you.
Sarah,
I love writing standards.
🙌🏻 Awesome work on this – thank you!
Just one thing – I didn’t think it’s possible to rename all Triggers as things stand currently? For example, I have a that uses the ‘Manually Trigger A Flow’ trigger…but the ‘Rename’ option is greyed out?
Ben,
I did not know that. Interesting. It’s kind of silly that we cannot rename manual triggers… thanks for sharing!
Does Microsoft publish a standard? Thank you
Ana,
No, Microsoft does not.