You’ve built your first Power Automate flow. Then a second. A few months later, you have fifty flows across three environments and nobody — including you — can find anything. Sound familiar?
I’ve been through this cycle more times than I’d like to admit. After years of building and consulting on Power Platform automations, I’ve learned that the difference between automation that scales and automation that collapses isn’t the complexity of the flows themselves. It’s the structure around them.
This post covers the three foundational patterns I wish someone had shown me on day one: naming conventions, environment strategy, and application lifecycle management. They’re not glamorous, but they’re the difference between a system you can maintain at 2am and one that makes you question your career choices.
Naming Conventions: Your Future Self Will Thank You
The most common automation mess I walk into isn’t a technical problem — it’s a findability problem. Teams with dozens of flows using names like “New Flow 3” or “Copy of HR Process” can’t answer basic questions: What does this flow do? Who owns it? What triggers it?
A good naming convention answers three questions at a glance: who owns it, what it does, and how it starts.
Here’s the pattern I use:
DEPT-ProcessName-TriggerTypeFor example:
HR-OnboardingChecklist-Scheduled— HR team’s onboarding flow that runs on a scheduleFIN-InvoiceApproval-Automated— Finance team’s invoice approval triggered automaticallyIT-TicketEscalation-Instant— IT’s ticket escalation triggered by a button or event
The department prefix is critical in shared environments. When you’re troubleshooting a failed flow at midnight, you need to know instantly who to call — not dig through documentation that may not exist.
What About Desktop Flows?
For desktop flows, I add a DF- prefix to distinguish them from cloud flows:
DF-DEPT-ProcessName-ActionFor instance, DF-FIN-LegacyExport-DataEntry tells you it’s a desktop flow owned by Finance that handles data entry into a legacy system. When your cloud flow orchestrates desktop flows, the naming makes the relationship visible in the run history.
The Consistency Tax
“But what if different teams want different conventions?” I hear this a lot. The answer is: pick one and enforce it. An imperfect convention applied consistently beats a perfect convention applied sometimes. The consistency tax — getting everyone to follow the same pattern — is far cheaper than the chaos tax of searching through randomly named flows.
Environment Strategy: Stop Building in Production
This is the pattern most teams skip until they learn the hard way. If you’re building and testing automations directly in your production environment, you’re one bad deployment away from breaking live business processes.
The minimum viable environment strategy for Power Platform is three environments:
- Development — Where you build and experiment freely
- Test/UAT — Where business users validate changes
- Production — Where live processes run
Each environment has its own Dataverse instance, its own connections, and its own data. Changes flow in one direction: Dev to Test to Production. Never the reverse.
Managed vs Unmanaged Solutions
This is where Power Platform’s model differs from traditional code deployment, and where I see the most confusion.
In development, you work with unmanaged solutions. Think of these as your source code — editable, flexible, and meant for active development. You group related components (flows, tables, apps) into a solution so they travel together.
In test and production, you deploy managed solutions. These are locked packages — you can’t edit individual components directly. Want to make a change? Go back to dev, make the change in the unmanaged solution, and re-deploy the managed version.
This feels rigid at first, and I won’t pretend the transition is painless. But managed solutions give you something invaluable: a known state. You can look at production and know exactly what version of each solution is deployed. You can roll back to a previous version. You can’t do that when everyone is editing flows directly in production.
The Single-Environment Trap
I’ve consulted for organisations running 200+ automations in a single environment. The symptoms are always the same:
- Someone edits a flow “just for testing” and breaks a live process
- Nobody knows which version of a flow is the “real” one
- Connection credentials are shared across test and live scenarios
- Rolling back a change means manually re-editing, with no guarantee you got it right
The fix isn’t complex. Create a dev environment, move your active development there, and treat production as read-only. The investment is a few hours of setup. The return is the ability to sleep at night.
Getting Started With Environments
If you’re currently running everything in one environment, here’s the practical path forward. First, create a dedicated development environment through the Power Platform admin center. Use a developer or sandbox type — you don’t need a production license for dev.
Next, identify your most actively developed solutions and recreate them in the dev environment. Don’t try to migrate everything at once. Start with the solution you’re currently working on, get comfortable with the dev-to-prod flow, and expand from there. The goal isn’t perfection on day one. It’s establishing the habit of “I build here, I deploy there.”
One thing I wish I’d known earlier: keep your environments as similar as possible in terms of security roles and connection types. The number one reason deployments fail isn’t the solution itself — it’s environmental differences that nobody documented.
ALM: Moving Automations Between Environments
Application Lifecycle Management is the fancy term for “how do I get my stuff from dev to production without breaking everything?” It’s also where most teams accumulate the most technical debt, because they skip it early and regret it later.
The core mechanism in Power Platform ALM is solution export and import. You build components inside a solution in dev, export it as a managed package, and import it into test and then production.
But raw export/import alone isn’t enough. Two features make the difference between a manual, error-prone process and a reliable pipeline:
Environment Variables
Environment variables let you parameterize values that change between environments — API endpoints, email addresses, feature flags, thresholds. Instead of hardcoding a production URL into your flow and then manually changing it after import, you define an environment variable and set the value per environment.
Variable: ApprovalThreshold
Dev value: 100
Test value: 500
Production value: 1000Your flow references ApprovalThreshold and gets the right value in each environment automatically. No manual edits after deployment. No “oops, I forgot to update the URL” incidents.
Connection References
Connection references solve the credentials problem. Every Power Automate flow needs connections — to SharePoint, to Dataverse, to external APIs. Without connection references, when you import a solution into a new environment, every flow breaks because the connections don’t exist there.
Connection references decouple the flow from specific credentials. You define a reference in your solution, and at import time you point it at the right connection in the target environment. The flow itself doesn’t change.
This is the pattern that makes zero-touch deployment possible. Combined with environment variables, you can import the same solution package into any environment and have it work correctly with that environment’s configuration and credentials.
I’ve seen teams manually update 15+ connection references after every deployment because they didn’t set up connection references from the start. That’s not just tedious — it’s a source of errors. One wrong connection and your production flow is reading from a test SharePoint site. Connection references eliminate this entire category of deployment bug.
The Pipeline Progression
Once you have naming, environments, and ALM basics in place, the next natural step is automation — automating the automation deployment. Power Platform pipelines or Azure DevOps integrations can move solutions through environments with approval gates and validation.
But don’t rush there. I’ve seen teams invest weeks building CI/CD pipelines before they have basic naming conventions or a second environment. The foundations come first. A manual but disciplined three-environment process beats an automated but chaotic single-environment one every time.
The Architecture Mindset
Here’s the core message: structure your automations like you’d structure code.
Developers learned decades ago that you don’t deploy code by editing files on the production server. You don’t name files “new_thing_3_final_v2”. You don’t share a single machine between development and production.
These same principles apply to automation. The technology is different — solutions instead of git repos, managed packages instead of Docker containers, environment variables instead of .env files — but the architectural thinking is identical.
The patterns in this post are boring. Naming conventions, environment separation, deployment discipline — none of this is exciting. But they’re the foundation that lets you build exciting things without the whole system collapsing when you need to make a change at scale.
Start with naming. Add a second environment. Put your components in solutions. These three steps alone will put you ahead of most automation teams I’ve worked with. The rest — pipelines, automated testing, governance policies — builds naturally from there.
You don’t need to implement everything at once. But the earlier you start thinking about structure, the less painful the journey from fifty flows to five hundred.
And if you’re a decision maker evaluating whether to invest in automation architecture — the cost of adding structure later is always higher than adding it now. Every flow built without naming conventions is a flow that needs to be renamed. Every solution deployed without environment variables is a solution that needs to be refactored. The compounding interest on architectural shortcuts is real, and it’s paid in developer time and deployment incidents.
Structure first. Scale second. Your future team will thank you.