Showing results for 
Search instead for 
Did you mean: 
Helper I
Helper I

Managed vs Unmanaged

When do you use a managed solution vs an unmanaged solution?  What are the pros and cons?  I will import a component for use with a canvas app.  I would like to be able to update and remove the component as needed.

Community Support
Community Support

Hi @rarroyo1 ,


Unmanaged Solution: The beginning state of solution is the unmanaged solution state. During this phase, you can add, edit, update, remove, delete, and test any of the components of the solution. You also have the ability to create restrictions on the components within the solution. Deleting the Unmanaged Solution only deletes the reference to the solution, not the customisation components. Less risk of losing customisations and data as more difficult to remove

Managed Solution: A managed solution is a finalized solution that can be distributed and installed. They are created by exporting an unmanaged solution by setting restrictions to prevent any further customizations. The whole point of Managed is locking down the Component states so they cannot be edited. Deleting the Managed Solution will remove all its customisations as well as data contained. Managed Solutions become read only once deployed so they cannot be manipulated.

  • Roll Back / removing a Managed Solution after deploying to production is simple
  • Preparing managed solutions for deployment requires more considerations for dependencies & merge behaviour
  • Once you deploy as Managed in production you cannot change back to unmanaged once the solution has been deployed

So, I think the unmanaged solution is more suitable for your case.


An excellent talk about Managed vs Unmanaged solution in this thread, see Managed vs Unmanaged solutions .


Hope this helps.



I listed to the podcast, and was wondering if the 'correct' way to import the component solution to Production is to export from Development first.  What not import the same solution zip file that I had imported to Dev?

A Production environment should never have unmanaged solutions installed on it so:-


if the solution you installed on dev is unmanaged you need to export a managed solution before importing it into production.

if the solution you installed on dev is managed you can import the same managed solution into production (after you've tested it).

If this post has answered your question please consider it for "Accept as Solution" or if it has been helpful give it a "Thumbs Up".

Thanks @ben-thompson . I also wondered if it's ok take the result of "pac pcf push" (basically the PowerAppsTools_XXX solution), and after that take that component  and add it in another solution, and export that as managed for production purposes. I was not sure if the unmanaged generation would skip making a minimized bundle, or other stuff like that.

In the very helpful explanation about "pac pcf push" it's stated that  ‘pcf push’ is not designed to replace the need for a cdsproj:

Kind regards,
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up."

pac pcf push: To be use only for quick deploy to DEV for completing unit testing of your control. Once unit testing is complete, add the control to your “PCF Custom Controls” project (unmanaged) and delete the solution that got created using pac pcf push command; it would look something like “PowerAppsTools_[prefix]”


Unmanaged: Recommended is to use this in DEV instance only. I normally create a separate solution that contains all my custom controls and I call it as “PCF Custom Controls”. After I deploy and test my control, I add it to this solution so I can deploy it to other environments.

Note: prefix of both the solution; PowerAppsTools & PCF Custom Controls must be same.


Managed: All other environments like UAT, Pre-Prod, Prod will have managed solution. When I export the solution from DEV I always export them as managed and import them in all other environments.


In your case it feels like you are developing the control for Canvas app and you are in the dev cycle where you want to update, deploy & test. I would recommend using pac pcf push until your control is ready. Once you think your control is ready then add it to your desired Solution with the same prefix you used in your pac pcf push. Delete the temporary PowerApps solution. To deploy it from DEV to other environments using the traditional export/import feature.


Hope this clarifies things a little better.

Power Maverick | Microsoft Business Application MVP



I have looked through the discussion thread and all but one contributor seems to advocate importing an unmanaged solution to sandbox environment.  In our case, we are automating the deployment on a managed solution from dev environment to sandbox test environment .  The advantage is that once the solution as passed testing in test, it can be pushed into UAT and other upstream managed environments without recreating the solution zip file.  I am wondering if this is the best approach.   I did notice an unmanaged layer in one of the Power Apps in Test so this maybe one reason for switching to the current deployment to test to be an unmanaged solution. Also I have seen a automated test tool for Power Apps that expected the tester to publish the Power App; prior to running a test, so again would this be another reason to have a unmanaged solution deployed to the test sandbox environment.


Helpful resources

Power Apps News & Annoucements carousel

Power Apps News & Announcements

Keep up to date with current events and community announcements in the Power Apps community.

Community Call Conversations

Introducing the Community Calls Conversations

A great place where you can stay up to date with community calls and interact with the speakers.

Power Apps Community Blog Carousel

Power Apps Community Blog

Check out the latest Community Blog from the community!

Top Solution Authors
Users online (1,794)