Most Power Automate teams hit a wall when it's time to move flows from development to production — and it's almost always because they skipped solution architecture. This lesson teaches you how publishers, managed vs. unmanaged solutions, and dependency tracking work together to make enterprise deployments predictable and safe.
Imagine your team has spent three months building a sophisticated set of Power Automate flows that handle invoice routing, vendor onboarding, and exception notifications. Everything works beautifully in your development environment. Then someone asks: "How do we get this into production?" You zip up the flows, import them manually, spend two days fixing broken connections, realize your environment variables didn't come across correctly, and discover that half the flows reference a custom connector that nobody documented. Sound familiar?
This is the problem that Power Platform solutions were designed to solve. A solution is a container — a structured package that holds your flows, connection references, environment variables, and other components together, along with metadata about who built them and how they relate to each other. When you understand solutions properly, you can move automation logic between environments predictably, safely, and repeatedly. Without that understanding, every deployment is an adventure in the worst sense of the word.
By the end of this lesson, you'll understand the architecture of Power Platform solutions well enough to make real design decisions: how to organize your flows inside solutions, what managed versus unmanaged means and why it matters for your deployment strategy, how publishers control namespacing and ownership, and how dependency tracking prevents you from accidentally breaking things. This knowledge is the foundation for everything else in enterprise-scale automation.
What you'll learn:
You should be comfortable creating basic flows in Power Automate. If you're newer to the platform, working through Getting Started with the Power Automate Interface first will give you the right mental model. You should also have access to a Power Platform environment where you have the System Customizer or Environment Maker role — you'll need it to create and export solutions.
A solution is not a flow. It is not a zip file. It is a structured, versioned container that can hold multiple types of components — cloud flows, canvas apps, Dataverse tables, custom connectors, connection references, environment variables, and more — and that carries metadata about what those components are, who owns them, and what they depend on.
Think of a solution like a shipping container rather than a cardboard box. A cardboard box holds things loosely. A shipping container has standardized dimensions, labeling, a manifest of contents, and a locking mechanism. You can load it onto any compatible ship. Solutions work the same way: they define a manifest of components and their relationships, which allows the Power Platform to import and configure them consistently regardless of which environment you're targeting.
The alternative — building flows outside of any solution — creates what the platform calls non-solution-aware flows. These exist in a personal "My Flows" context and cannot be exported in a structured way. You can download a single flow as a package, but that package doesn't know about the other flows it interacts with, the connection references it depends on, or the environment variables it reads. Moving non-solution-aware flows between environments is essentially manual work every time.
Warning
Any flow you create in the "My Flows" section of Power Automate is not solution-aware by default. This seems fine early on, but becomes a serious problem when your organization needs to promote that flow to production or audit it through governance tooling. Start every production-bound flow inside a solution from day one.
To create a solution, navigate to Power Automate (make.powerautomate.com), select your target environment from the environment picker in the top-right corner, then click Solutions in the left navigation panel. From there, click New solution and you'll be prompted to provide a display name, a name (the unique internal identifier), a publisher, and a version number. We'll talk about each of those in depth shortly.
When you create a solution, one of the first decisions you make is choosing a publisher. A publisher is an identity record that represents the person or organization responsible for the solution. It has two properties that affect every component inside your solution: a display name and a prefix.
The prefix is the part that really matters architecturally. Every component you add to a solution — every environment variable, every connection reference schema, every custom connector — gets the publisher's prefix prepended to its unique internal name. For example, if your publisher has the prefix contoso, an environment variable called APIBaseUrl will have the internal name contoso_APIBaseUrl. This namespacing serves two purposes.
First, it prevents naming collisions. If Contoso installs a third-party solution that also creates an environment variable called APIBaseUrl, and that vendor's prefix is fabrikam, you now have contoso_APIBaseUrl and fabrikam_APIBaseUrl as distinct components. No conflict.
Second, it establishes ownership and provenance. When you look at a solution component in another environment and see the prefix, you immediately know who created it. This matters during audits and troubleshooting — especially when you have multiple solutions installed across the same environment.
Tip
Never use the default Microsoft publisher (prefix new) for production work. Microsoft reserves this publisher for its own components, and using it blurs ownership. Create a dedicated publisher for your organization — something short and recognizable like your company abbreviation — and use it consistently across all solutions your team creates.
To create a publisher, go to Solutions → Publishers → New publisher. You'll set the display name, name, prefix, and choice value prefix (a numeric prefix for option set values in Dataverse). Once created, a publisher persists in that environment and can be reused across all your solutions.
Publisher prefixes must be between 2 and 8 characters, lowercase letters and numbers only. Pick something meaningful. acme, wcsd, or fin (for a finance team) are all good examples. x is technically valid but tells you nothing about provenance.
This is the distinction that confuses people most, and it's worth taking the time to understand it properly. The difference is not about features — a managed and unmanaged solution can contain identical components. The difference is about intent and control.
An unmanaged solution is what you work with during development. When you create a solution in a development environment and start adding flows to it, that solution is unmanaged. You can open any component and edit it freely. You can add, remove, and rearrange components at will. Unmanaged solutions are the raw, editable form of your work.
Technically, an unmanaged solution doesn't "own" its components exclusively. Dataverse maintains a single master record for each component, and the unmanaged solution just contains a reference to it. This means a component can appear in multiple unmanaged solutions simultaneously. If you have a flow that belongs to both a "Core Automation" solution and a "Finance Flows" solution, the flow itself exists once in Dataverse — both solutions just point to the same record.
Key insight
When you export an unmanaged solution, you're exporting a snapshot of the current state of those components. This is useful for backup but not for deployment, because the receiving environment will treat the imported components as editable, which can lead to environment drift — someone modifies the flow directly in production rather than through the proper promotion process.
A managed solution is what you install into non-development environments — test, UAT, staging, production. When you export a solution as managed, Power Platform transforms it into a deployment artifact with specific characteristics:
Components are locked. You cannot edit a flow, environment variable, or connection reference that was installed as part of a managed solution. The only way to change it is to update the source solution in your development environment and re-deploy.
Uninstall is clean. When you remove a managed solution, every component it installed is removed with it. There's no orphaned debris left behind.
Layering is possible. You can install additional unmanaged customizations on top of a managed solution in the same environment. This is called the active layer — the managed solution provides the base, and you can apply environment-specific tweaks as an unmanaged layer above it.
The practical workflow is: develop in an unmanaged solution → export as managed → import into test → import into production. This is the foundation of proper Application Lifecycle Management (ALM), which you can explore in depth in Deploying and Managing Power Automate Solutions Across Environments.
Warning
Never import an unmanaged solution into your production environment. Doing so makes every component editable in production, which defeats the entire point of version control and change management. Production components modified outside of your official deployment pipeline create drift that is very difficult to reconcile.
In the Solutions list, select your solution and click Export solution. Power Platform will ask you to publish your customizations first (always say yes — this flushes any unpublished changes into the solution). Then it asks whether to export as Managed or Unmanaged.
For development backups or peer review: unmanaged.
For deployment to any non-development environment: managed.
For production: always managed, no exceptions.
Understanding how solution layers stack is important when you have multiple solutions installed in the same environment. Power Platform uses a layering model where the most recently applied customization wins.
Imagine you have a managed solution version 1.0 installed in production. It includes a flow called ProcessInvoice. Someone in your team adds an unmanaged customization directly in production (which, as we said, you should avoid, but it happens). That unmanaged change forms the active layer — it overrides what the managed solution defined.
When you deploy version 1.1 of your managed solution, the upgrade might or might not replace that active layer, depending on how the component was modified. This is a common source of confusion and bugs. The safest practice is to keep production environments clean of unmanaged customizations, reserving them strictly for what your managed solution delivers.
You can inspect the layers on any component by navigating to the solution, finding the component, clicking the three-dot menu, and choosing See solution layers. This panel shows you the stack of modifications and which layer is currently active.
Every component in a solution can depend on other components. A cloud flow that connects to SharePoint depends on a connection reference that points to a SharePoint site. That same flow might read an environment variable to know which SharePoint URL to use. When you move the solution to another environment, both of those dependencies — the connection reference and the environment variable — need to exist and be properly configured, or the flow will fail.
Power Platform tracks these relationships automatically. When you add a flow to a solution, the system inspects it and records what it references. You can see this dependency graph by going to your solution, clicking the three-dot menu on any component, and selecting Show dependencies. You'll see two tabs: Required components (what this component needs) and Dependent components (what needs this component).
Solution-internal dependencies are components that depend on other components within the same solution. For example, if you build a child flow that is called by a parent flow, and both live in the same solution, that dependency is tracked internally. When you export and import the solution, both flows arrive together.
Cross-solution dependencies occur when a component in Solution A depends on a component that lives in Solution B. For example, you might have a "Core Connectors" solution that defines shared connection references, and your "Invoice Processing" solution's flows reference those connection references. When you import the Invoice Processing solution, the Core Connectors solution must already be installed in the target environment, or the import will fail.
This is actually a useful architectural pattern. Building a "foundation" solution that holds shared connection references, environment variables, and custom connectors — and keeping your domain logic in separate solutions on top — keeps things modular and reusable.
Tip
Use connection references deliberately as a dependency management tool. Instead of embedding credentials directly in a flow, use a connection reference that is defined in a foundation solution. All flows that need SharePoint access point to one contoso_SharePointOnline connection reference. When you need to change the service account, you change it once in one place.
The most common import failure is a missing dependency. This happens when:
To avoid the first two situations, always do a dependency check before export. Go to your solution, look at each flow's dependencies, and make sure every referenced component is either inside your solution or already guaranteed to exist in every target environment.
The third situation is addressed by including your custom connectors in the solution — either the same solution or a prerequisite foundation solution. You can read more about structuring custom connectors for production in Advanced Power Automate: Custom Connectors and HTTP Actions for Production Integration.
Environment variables deserve specific attention because they're one of the most powerful and most misunderstood solution components.
An environment variable is a named value that you define once in your solution and then reference in your flows using the @{parameters('contoso_APIBaseUrl')} syntax. The key property: the value of the environment variable can differ between environments, even though the definition (the schema — name, type, default value) travels with the solution.
When you import a managed solution that contains environment variables, the import wizard prompts you to set the current values for each variable. This is how the same solution can connect to a development SharePoint site in your dev environment and the production SharePoint site in your production environment, with zero code changes between them.
Note
There is a distinction between the environment variable definition (the schema, which lives in the solution) and the environment variable value (the current value, which is environment-specific and is stored outside the solution). When you export a solution, you export the definition but not the current value. This is intentional — it prevents production credentials from leaking into your exported package.
Every solution has a version number in the format Major.Minor.Build.Revision — for example, 1.0.0.0. You set this manually before exporting, and it serves several purposes.
First, it gives you a history. If something breaks in production, you can look at the version number and trace it back to exactly which export caused the problem.
Second, it controls upgrade behavior. When you import a newer version of a managed solution over an existing installation, Power Platform runs an upgrade (or update, depending on your choice). An upgrade removes the old solution components and replaces them. An update applies changes on top. Choosing wrong here can create stale components or broken dependencies.
The convention most teams use: increment the minor version for each sprint or feature release, increment the major version for significant architectural changes, and keep the patch and revision numbers for hotfixes.
For teams using Azure DevOps or GitHub Actions pipelines to automate exports and deployments, the version number is typically injected automatically from the build pipeline. This is covered in detail when you dig into ALM pipelines for Power Platform.
Let's build a properly structured solution from scratch. You'll need access to a Power Platform development environment where you have the Environment Maker role.
Step 1: Create a publisher
Navigate to make.powerautomate.com, select your development environment, go to Solutions → Publishers → New publisher. Set:
Wicked Smart CorpWickedSmartCorpwsc10000 (any 5-digit number unique to your org)Save the publisher.
Step 2: Create a solution
In Solutions, click New solution. Set:
Invoice AutomationInvoiceAutomationWicked Smart Corp1.0.0.0Step 3: Add an environment variable
Inside your new solution, click New → More → Environment variable. Set:
Invoice SharePoint Site URLwsc_InvoiceSharePointSiteURLTexthttps://yourcompany.sharepoint.com/sites/invoicesStep 4: Add a connection reference
In the solution, click New → More → Connection reference. Set:
WSC SharePoint Onlinewsc_SharePointOnlineConnect it to an existing SharePoint connection in your environment (create one first if needed from the Connections page).
Step 5: Create a flow inside the solution
Still inside the solution, click New → Automation → Cloud flow → Automated. Build a minimal flow that triggers on a SharePoint item creation. In the trigger's Site Address field, use the dynamic content picker to select your Invoice SharePoint Site URL environment variable.
Step 6: Verify dependencies
Select your flow in the solution, click the three-dot menu, and choose Show dependencies. You should see the connection reference and the environment variable listed as required components. Confirm they are both in the solution.
Step 7: Export as managed
Click Export solution, publish customizations when prompted, select Managed, and download the zip file. Open the zip and look at the solution.xml file inside — you'll see the component manifest, the publisher information, and the dependency declarations in readable XML.
"My flow was inside a solution but broke when I imported it elsewhere." Most likely a missing dependency. Check whether every connection reference and environment variable the flow uses is included in the solution. Open the flow in the source environment, go to its dependencies, and cross-reference against the solution contents.
"I can't edit a flow after importing into the test environment." You imported it as managed, which is correct. To edit it, make changes in your development environment, increment the version number, export as managed again, and re-import. Don't try to edit directly in the test environment.
"The environment variable shows the wrong value in production." Remember: the solution exports the definition, not the value. When importing, you must set the value during the import wizard. If you skipped that step, go to Solutions → Default Solution → Environment variables in the production environment and set the current value there.
"I accidentally built flows in My Flows and now need to move them into a solution." Power Automate does allow you to add an existing flow to a solution: go to the solution, click Add existing → Automation → Cloud flow, and select your flow. However, this should be a one-time rescue operation, not a regular practice.
"My solution import fails with 'missing required component.'" A cross-solution dependency isn't satisfied. The import message will tell you the schema name of the missing component (it'll have a publisher prefix). Find which solution that component belongs to, import that solution first, then retry.
Solutions are the architectural foundation of everything else you'll do with Power Automate at enterprise scale. They're how you control who owns components, how you move automation safely between environments, and how you avoid the chaos of manual copy-paste deployments.
Here's what to carry forward:
From here, the natural next step is understanding how environments separate your dev, test, and production contexts, and then learning how to automate the promotion process using ALM pipelines. If your flows are complex enough to involve security, check out how connection references and credentials management fits into a governed solution deployment model.
Solutions aren't glamorous. They're scaffolding. But scaffolding is what lets you build something tall without it falling over.