Use an unmanaged solution as the editable source in development. Export and deploy a managed solution to test, user acceptance and production environments. That is Microsoft's ALM recommendation, and it is a better rule than choosing between “flexibility” and “control” for each deployment.
The real complication is solution layering.
Managed and unmanaged in plain English
An unmanaged solution contains editable customisations. Makers use it in the development environment where the application is authored.
A managed solution is a distributable package installed into a target environment. Its components are serviced through managed updates, upgrades or removal of the solution rather than ordinary editing of the source package.
Managed does not mean that nothing in the target can ever alter behaviour. An unmanaged active customisation can sit above managed layers, and multiple managed solutions can affect the same component.
Why unmanaged production changes cause trouble
Editing a managed component directly in production can create an active unmanaged layer. That top layer can override a later managed deployment, leaving the team wondering why the imported change did not appear.
Microsoft's troubleshooting guidance identifies this exact failure pattern. Removing the active customisation or deliberately overwriting it can change behaviour, so inspect the component's solution layers before acting.
Do not remove layers casually in a live environment. Record the current state, dependencies and rollback route first.
Update, upgrade and patch are not synonyms
Update: brings a newer solution version but does not delete components that were removed from the newer source.
Upgrade: can remove components no longer present and rolls the solution forward. It can be applied immediately or staged where supported.
Patch: carries a small set of changes on top of a parent solution. Microsoft's current ALM guidance says patches are not recommended as the default approach, although they remain available for specific servicing scenarios.
Choose the action based on the intended component lifecycle, not merely which option imports fastest.
A dependable release pattern
- Make changes in the unmanaged solution in development.
- Increment the solution version.
- Check dependencies and run appropriate validation.
- Export a managed artifact or let the pipeline create it.
- Deploy the same artifact to test.
- Test representative user permissions, connections, flows and business behaviour.
- Promote the same artifact to production.
- Inspect deployment and application health after release.
- Keep the artifact and recovery record.
Power Platform pipelines deploy managed solutions to target environments and preserve the solution artifact through configured stages. More complex teams may also use source control and CI/CD tooling.
What to inspect when production differs from development
- Open See solution layers for the affected component.
- Look for an unmanaged active layer above the expected managed layer.
- Confirm that the correct solution version reached the environment.
- Check whether another managed solution also contains the component.
- Verify connection references and environment variables.
- Check whether the chosen update action should have removed an old component.
- Reproduce the issue with a representative non-admin account.
Do not assume re-importing will fix a layering problem. It may leave the effective top layer unchanged.
Licensing and proof boundary
Solutions are part of the platform's ALM mechanism, but the applications, Dataverse use, premium connectors, pipelines and Managed Environments can introduce separate licence requirements. Verify the current licensing guide for the actual design and users.
A clean import proves that the package was accepted. It does not prove that permissions, connections, data policies or business tests passed.
For help reading solution layers and planning a safe release, join the Power Apps Builders Space.