Naming Conventions in Power Automate

A flow named "Untitled" or "Instant cloud flow-3" seems like a minor detail at first. But as soon as more than a handful of flows exist in a tenant, and several people build and maintain them, this exact name determines whether someone understands what the flow does within five minutes, or spends half an hour clicking through trigger after trigger. At NordFlux, we rely on fixed naming conventions for every digital employee we build for you, because they are the cheapest governance measure there is: no additional tool, no license, just discipline when creating things.

Microsoft therefore treats naming conventions not as optional, but as a fixed part of the official Power Automate coding guidelines and the Power Platform governance recommendations. This article summarizes the most important rules for flows, actions, connections, and environments, derived directly from Microsoft documentation, so you can codify them as a style guide within your team. This way, you always keep control over how your automations grow, instead of having to clean things up laboriously later.

Why is a naming convention the foundation for governance?

According to Microsoft, a Center of Excellence for Power Platform rests on several pillars, including data security, access rights, and monitoring. One of these is solution development, and there Microsoft explicitly names "coding standards and naming conventions to ensure readability and maintainability" as a governance task. The reason is obvious: without consistent names, you can neither report automatically nor quickly determine, in an emergency, which flow uses which connection or which environment is in production. Naming conventions are therefore not a cosmetic question, but the foundation on which access control, monitoring, and reporting can function at all.

How should you name flows, triggers, and actions?

For the components within a flow, the Microsoft documentation Use consistent naming for flow components lists five concrete recommendations:

• Descriptive names instead of generic labels. A trigger should not be called "Trigger1", but for example "Receive new email", so that its purpose is immediately clear.
• CamelCase or underscores to separate words. Actions like "sendEmailNotification" or "send_email_notification" are readable at a glance, whereas "sendemailnotification" is not.
• Prefixes for categorization. Microsoft suggests marking triggers with "Trg_", actions with "Act_", and variables with "Var_", so that the role of a component is immediately recognizable.
• Consistency across all flows. A team that applies the same convention in every flow does not have to decipher an unfamiliar style for every new colleague's flow.
• Documentation of the convention. A style guide, for example on a shared SharePoint page, ensures that new team members know the rules instead of having to infer them from existing flows.

In addition, Microsoft recommends attaching comments to actions, especially for complex flows or when several people work on them. A name says what an action does, a comment says why it was built that way.

What distinguishes connections from connection references when it comes to naming?

With connections, the naming question quickly becomes confusing, because Power Automate has two different concepts. According to the Benefits of using solution-aware cloud flows, connections are user-specific configurations with authentication details that are embedded directly into actions outside of solutions. If you change a connection, every action that uses it must be updated individually. Connection references, on the other hand, are a pointer to a connection and are used in solution-aware cloud flows. They separate the flow design from the specific login and can be swapped between development, test, and production environments without you having to touch every single action.

For the naming convention, this means: a connection reference should carry the service and the purpose of use in its name, for example "conref_sharepoint_sharelist", instead of relying on the generic suggestion that the flow designer assigns automatically. This way, when moving a solution between environments, you immediately recognize which reference addresses which external service, without having to open every action individually.

How do you build a naming convention for environments?

Fixed rules are also needed above the level of individual flows. The Microsoft's environment strategy recommendations suggest a pattern made of four building blocks: lifecycle stage, region, business unit, and purpose, for example "Prod-US-Finance-Payroll". Alternatively, in smaller organizations, a simpler scheme such as "Contoso Dev", "Contoso Test", and "Contoso Prod" is often already sufficient, as long as it consistently separates which environment serves which purpose. According to Microsoft, it is also important not to include confidential information in environment names, because these are visible to anyone with access to the Admin Center, and to keep the names short enough that they remain manageable even after years of growth.

How do you consistently enforce a naming convention within your team?

A convention that exists only on paper fizzles out in practice. Microsoft therefore recommends documenting the rules in a style guide and sharing them with the maker community through a shared point of contact, such as a SharePoint page, instead of leaving them in individual people's heads. For larger organizations, there is additionally the Power CAT Toolkit, which supports code reviews and automatically detects when flows deviate from documented best practices, including naming conventions. This way, control over growing flow landscapes is retained even as more and more business units build their own automations.

If you want to set up a naming convention for your company but don't want to start from scratch, NordFlux for Power Automate supports you in defining governance rules and applying them to existing flows, without interrupting running processes.

Frequently asked questions

Do I really have to use prefixes like "Trg_" or "Act_" for every component?

No, Microsoft mentions prefixes as one possible option for categorization, not as a requirement. What matters is that you agree on a scheme within your team and apply it consistently, whether with prefixes, CamelCase, or underscores.

Where is the best place to document our naming convention?

Microsoft recommends a central location accessible to all creators, for example a SharePoint page serving as a Power Platform hub for your maker community. What matters less is the specific tool and more the fact that every new person finds the rules before creating their first own flow.

Does the same naming convention also apply to connection references in solutions?

Yes, even though connection references technically work differently from simple connections, they should follow the same descriptive naming rules. A name that states the connected service and the purpose of use is especially helpful when moving solutions between development, test, and production environments.

How are naming conventions and environment strategy related?

Both topics are interconnected: a clear naming convention for environments such as "Prod-US-Finance-Payroll" immediately shows which flows and connections are allowed to land in which environment. Without this clarity, even the best flow naming cannot be meaningfully embedded into a larger governance structure.

Is a naming convention worthwhile even with only a few flows?

Yes, precisely because the number of flows in most organizations grows faster than planned, a convention introduced early pays off. Renaming hundreds of existing flows after the fact is significantly more effort than consistently applying a simple rule from the start.