Power Automate Standards: Naming Conventions

Power Automate Standards: Naming Conventions
Table of Contents
• Why Use Power Automate Naming Conventions?Flow NamesAction NamesTrigger NamesVariable NamesConnection 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 ExamplesBad ExamplesBad Reason
Send Daily Status Report (Scheduled)Send Daily Status ReportNo trigger type at end of name
Get Currency Rates From Web (Automated)Currency Rates From WebNo 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 ExamplesBad ExamplesBad Reason
Get Items: Inspections TableDownload Items From The Inspections TableOriginal SharePoint connector action name missing
Compose: Email message bodyComposeMissing 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 ExamplesBad ExamplesBad Reason
vQuantityInBoxvarQuantityInBoxDo not prefix with var
vEmployeeFullNamestrEmployeeFullNamePrefix str to denote a string data type is not necessary
vIsPastDuevispastdueUse 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 ExamplesBad ExamplesBad Reason
SvcAcct-SharePoint CurrencyExchangeRates-ac3d5SharePoint CurrencyExchangeRates-ac3d5Missing noun at beginning
SvcAcct-Dataverse CurrencyExchangeRates-be005SvcAcct-DataverseNo solution name or unique identifier found
SystemAlerts-Office 365 Outlook CurrencyExchangeRates-32a0cDavidJohnson-Office 365 Outlook CurrencyExchangeRates-32a0cNoun is not generic.





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.

Subscribe
Notify of
guest

30 Comments
Oldest
Newest
Inline Feedbacks
View all comments
Andrew Boles
Andrew Boles
10 months ago

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 Boles
Andrew Boles
10 months ago

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!

Matt Bell
Matt Bell
10 months ago

Personally I use var, because other words begin with v so typing var will only bring up my variables when typing

Mohammed Taufiq
Mohammed Taufiq
10 months ago

Thanks for sharing a valuable information ☺️

Maciej Wachowiak
10 months ago

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.

Paul CJ
Paul CJ
10 months ago

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.

Jenny
Jenny
10 months ago

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!

Jenny
Jenny
10 months ago
Reply to  Jenny

I also think it looks nice in a for loop title 😀

2023-07-31_19-20-23.png
Naresh K
Naresh K
7 months ago

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.

Marc
10 months ago

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
10 months ago

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.

Screenshot_20230801-120703.png
rudi
rudi
10 months ago

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?

Olivier Jenkins
Olivier Jenkins
10 months ago

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.

Filip Giera
Filip Giera
8 months ago

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 🙂

Steve Morley
Steve Morley
10 months ago

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.

Sarah
Sarah
8 months ago

Wow! A very good article. Thank you.

Ben Pomeroy
Ben Pomeroy
7 months ago

🙌🏻 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?

Ana Lasmana
6 months ago

Does Microsoft publish a standard? Thank you