Is there anyway to remove a managed package (Action Plans) that was installed into a managed package dev (My Managed Package) org after being released? Assuming yes, are there any dangers or complications with doing this? Again assuming yes, once an installed org upgrades to the newer version of our managed package (My Managed Package) would we be able to remove the other managed package (Action Plans)?


I'm working on a managed package that includes the Action Plans managed package module. We now need to customize Action Plans and to do this need to switch to the unmanaged version. We don't extend the package, just have buttons from it on some page layouts which we can remove. Seems like this may be possible, but could have some potential dangers. Since managed packages aren't so undo friendly and don't have sandboxes I'm hoping someone out there may have actually done this and be able to provide some real world info.

2 Answers 2


Yes we've done this and been successful.

However your correct to be cautious about it though. We've had things go wrong under the hood in the past (typically with more complex dependencies than your describing here though). So long as you're not under major pressure to release Salesforce support have in our experience been able to pick through things for you and sort things out, just be sure not go messing around further if things appear odd.

Uninstalling from Packaging Org. So long as you no longer have any references to it, it will uninstall as normal, even from a packaging org. If however you've made references to it via fields lookups for example, that you cannot remove or edit out from your package, because those have been released you will not be able to break the dependency. This doesn't mean you cannot install the unmanaged version, as this will be in the your packaging org namespace. Its just that it would look a little odd to admins in your subscriber orgs to see the same classes, objects etc from the Action Plan namespace and your package namespace, other than this urglyness that may be tolerable.

Uninstalling from Subscriber Org. This again will be possible once you the subscriber org has upgraded to your new dependency free version of your main package.

  • I concur with Andrew Fawcett. I had to do this myself just yesterday. I had a couple of Visuaforce pages/Apex controllers in a package development org that referenced custom fields from another installed package. Once I removed those hard binding from my code, I was able to uninstall the package even though I already had managed-released versions of the package that referenced them.
    – tlfu
    Commented Jun 25, 2013 at 11:59

So, I have an update on this. The other day, I was trying to remove a package (I'll call this PackageA) from a packager org for another managed package (which I'll call PackageB). There were some Visualforce pages in PackageB that had references to custom fields installed by PackageA. Once I removed these hard references from these Visuaforce pages, and deactivated some Record Types included by PackageA, I was able to uninstall PackageA from the PackageB packager org.

Yesterday, I tried to uninstall PackageA from a packager org for a different managed package (which I'll call PackageC). I think I've run into a brick wall here. PackageC contains some custom Report Types that have references to fields from PackageA. In order to uninstall PackageA, I need to remove these field references from the packaged Report Types, but removal of fields from a previously packaged Report Type does not appear to be possible. When I try to do it via the Salesforce Report Type layout tool, I get this: http://screencast.com/t/KaLvc8XqC. If I try to edit the Report Type meta-data file and deploy it to the PackageC packager org, I get the following error:

error 25-Jun-2013 15:56:42 Error: reportTypes/PaymentTransaction_Reports_Clean_Version.reportType(PaymentTransaction_Reports_Clean_Version):Cannot remove objects or fields from a managed released custom report type.

So, this seems like one situation where you can't uninstall a previously installed package.

  • Ditto, what a pain. Commented Jun 26, 2013 at 22:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .