Power Automate Naming Conventions That Scale

Open the Power Platform Admin Center. Navigate to your production environment. Click into the flow list. What do you see?

“My Flow.” “Test - Copy.” “John’s Approval Flow (2).” “Untitled.” Fourteen flows named “When an item is created.”

This is the reality of most Power Automate tenants. And it’s not a minor inconvenience. When something breaks at 2 AM, you need to find the right flow in seconds. When a maker leaves the organization, someone else needs to understand what each flow does. When you run an inventory across 300 flows, naming is the difference between actionable data and noise.

Naming conventions are the cheapest governance control you can implement. No licenses required. No premium features. Just discipline and a standard that everyone follows.

The Naming Pattern

Every cloud flow name should follow this structure:

{Domain}-{Entity}-{Action}-{Trigger}

Four segments, hyphen-separated, no spaces. Each segment serves a specific purpose.

Domain Codes

The domain identifies which business area owns the flow. Use short, uppercase codes:

If your organization has specific departments that don’t fit these codes, create your own. The key is consistency. Pick a list, publish it, and enforce it.

Entity

The entity is what the flow operates on. Use the business object name, not the Dataverse table name. “Evaluation” not “cr4b2_evaluation.” “Invoice” not “salesinvoice.” Keep it readable by a business user.

Action

The action describes what the flow does. Common actions:

• Create - creates a record or resource
• Notify - sends a notification (email, Teams, push)
• Sync - synchronizes data between systems
• Approve - routes through an approval process
• Archive - moves or flags records for archival
• Validate - checks data against business rules
• Calculate - computes values (totals, scores, dates)
• Export - generates files or reports

Trigger

The trigger tells you what starts the flow. This is critical for troubleshooting. If you know a flow fires on record creation and the issue started after someone bulk-imported records, you have your answer.

Common trigger suffixes:

• OnCreate - when a record is created
• OnUpdate - when a record is modified
• OnStatusChange - when a status field changes
• Scheduled - runs on a timer (daily, weekly, hourly)
• Manual - triggered by a button or user action
• OnEmail - triggered by an incoming email
• OnApproval - triggered by an approval response

Real Examples

Here’s what good naming looks like in practice:

When you have 50 flows in an environment, these names let you filter by domain, sort alphabetically, and find exactly what you need. When you have 200 flows, this naming convention is the only thing standing between you and chaos.

Connection Reference Naming

Connection references are the mechanism that lets you deploy solutions across environments without hardcoding credentials. They get their own naming convention:

{publisher}_{connector}_{purpose}

All lowercase, underscores as separators.

Why does the publisher prefix matter? Because when you import a managed solution, the connection references show up in the target environment. If two different ISVs both have a connection reference called “SharePoint,” you have a collision. The publisher prefix prevents that.

Environment Variable Naming

Environment variables store configuration values that change between environments. URLs, email addresses, feature flags, thresholds. Same idea:

{publisher}_{Domain}_{VariableName}

Examples:

• contoso_HR_NotificationMailbox - the email address that receives HR notifications
• contoso_FIN_ApprovalThreshold - the dollar amount that triggers executive approval
• contoso_IT_ServiceNowBaseUrl - the ServiceNow instance URL for the IT integration
• contoso_SALES_LeadScoringEnabled - feature flag for the lead scoring flow

Flow Description Template

The flow name tells you what. The description tells you why and how. Every flow should have a description that follows this template:

Purpose: [One sentence explaining the business reason]
Owner: [Team or role, not a person's name]
Dependencies: [External systems, other flows, specific data]
SLA: [Expected run time and any time-sensitive requirements]
Last reviewed: [Date of last review]

Example:

Purpose: Sends email notification to the evaluation manager when
an employee submits their self-evaluation for review.
Owner: HR Operations Team
Dependencies: Office 365 Outlook connector, Evaluation table,
contoso_HR_NotificationMailbox environment variable
SLA: Must complete within 5 minutes of status change
Last reviewed: 2026-03-01

This takes 30 seconds to write. It saves hours when someone is troubleshooting at 11 PM.

Enforcement

A naming convention that nobody follows is just a document. Here’s how you actually enforce it.

The Regex Pattern

If you want to validate flow names programmatically, here’s a regex pattern that matches the convention:

^[A-Z]{2,5}-[A-Za-z]+-[A-Za-z]+-(?:OnCreate|OnUpdate|OnStatusChange|Scheduled|Manual|OnEmail|OnApproval)$

This matches:

• 2-5 uppercase letters for the domain
• One or more letters for the entity
• One or more letters for the action
• A known trigger suffix

You can expand the trigger list as needed. The point is that the check is automatable.

How Do You Name Child Flows and Desktop Flows?

Child flows and desktop flows follow the same four-segment naming convention with one addition. Child flows append a _Child suffix so you can instantly distinguish them in an inventory. Desktop flows replace the trigger segment with Desktop, making it clear which runtime executes them. Both approaches keep your naming consistent across flow types.

Child flows (flows called by other flows) follow the same convention but add a _Child suffix:

HR-Evaluation-SendEmail-OnCreate_Child

Desktop flows use a similar pattern but replace the trigger segment with Desktop:

FIN-Invoice-ExtractLineItems-Desktop

This makes it immediately obvious in an inventory which flows are cloud flows, which are child flows, and which are desktop flows.

Start Today

You don’t need to rename every flow in your tenant on day one. Start with new flows. Apply the standard going forward. Then work through the backlog in batches, prioritizing production environments and business-critical flows.

The naming convention is the foundation for everything else in this series. Environment strategy, solution awareness, and flow inventory all become dramatically easier when every flow has a name that tells you exactly what it is.

Power Automate Governance - The Enterprise Playbook

This article is part of a 10-part series:

1. Naming Conventions That Scale
2. Environment Strategy - Dev Test Prod
3. Solution-Aware Flows
4. Flow Inventory
5. Pipelines - Dev to Prod
6. CoE Starter Kit
7. AI-Powered Flow Review
8. Versioning and Source Control
9. The Governance Repo
10. Weekly Governance Digest

AZ365.ai - Azure and AI insights for architects building on Microsoft. Follow Alex on LinkedIn for architecture deep dives.