A Power Platform solution is the package used to move supported apps and components between environments and manage their lifecycle. It can contain canvas apps, model-driven apps, flows, tables, forms, custom connectors and other components. It does not contain the business data stored in Dataverse tables.
Solutions improve release discipline. They do not automatically find every dependency, secure every connector or make a poorly owned application supportable.
The three ideas to understand first
1. Unmanaged is the editable source
Build and change an unmanaged solution in the development environment. This is the source from which you export a release artifact.
Do not use the Default Solution as your project's organising container. Create a named solution with a publisher you control.
2. Managed is the release artifact
Microsoft recommends managed solutions for environments that are not development environments for that solution, including test and production.
Managed components participate in solution layering. They are not simply “locked files”. Other managed layers, updates, upgrades and unmanaged active customisations can affect the effective behaviour.
3. A solution carries configuration, not operational data
Solutions package metadata and certain configuration data. They do not move customer, case or transaction rows between environments.
Plan test data, configuration migration and reference data separately. Never copy production data into development merely to make a demonstration convenient.
What to add to a solution
Add the components needed for one coherent business capability. Common examples include:
- the app and its flows;
- Dataverse tables, columns, forms and views;
- security roles created for the solution;
- connection references;
- environment variables;
- custom connectors and required web resources.
Adding a component can offer to include required objects. Review the result rather than assuming all dependencies are present or that every suggested object belongs in the package.
Connection references and environment variables
A connection reference lets a solution-aware app or flow refer to a connector connection without baking one maker's connection directly into the component.
An environment variable holds a value that differs by environment, such as a site URL or configuration setting. Treat secrets separately. Do not put credentials into plain environment-variable values.
These mechanisms make target configuration explicit, but somebody still needs permission to create or select the target connection.
A safe first solution
- Create or select a non-production development environment.
- Create a publisher with an appropriate prefix.
- Create an unmanaged solution.
- Add the app, flows and required components.
- Replace direct connector bindings with connection references where supported.
- Add environment variables for environment-specific values.
- review dependencies and run Solution Checker where it applies.
- increment the version and export a managed artifact.
- import it into a test environment.
- verify permissions, connections, flows, data access and user tasks.
Keep the exported artifact and release record. A successful import is not enough evidence on its own.
Common failures
Missing dependency: The source environment contained a component that was not added to the solution or does not exist in the target.
Connection failure: The target identity lacks a valid connection or connector permission.
Unexpected behaviour after import: An unmanaged active layer or another managed layer is above the component you expected to control runtime behaviour.
Flow stays off: The target connection, owner, permission or trigger configuration is incomplete.
Deletion does not arrive: Updates and upgrades handle removed components differently. Review the current solution lifecycle guidance before choosing the import action.
For practical solution packaging and deployment checks, join the Power Apps Builders Space.