function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Removing items from managed package

I have a managed package which has been published to the AppExchange.  I now want to remove a couple of items from the package and re-publish it.  But when I look at the package detail, most of the items in the package do not have a Remove link next to them.  How can I remove them?
Mike LeachMike Leach

I'm noticing a "Beta" checkbox during the package upload process with the following help related to it:

"Uploading a managed package as beta ensures that any components added since the last released (non-beta) upload are fully editable and can be removed from the package. A beta version is not publicly listed on the AppExchange Directory; it is only installable by knowing the install URL. In addition, beta versions may only be installed in a Sandbox or Developer Edition org."

Perhaps there's a correlation with your issue. This is all just a head scratcher for me...:smileyindifferent:




Yes - I am in the same place with one of my applications.  It appears that once you switch from a Beta to a Managed application there is no way to go back - even if the application has never been installed by another organization.  As a managed application, you cannot delete any components.

Can someone from SF comment on what steps are available to developers to "unmanage" an application?

Who do we contact? I tried the "developer" support desk but I only had the option of leaving a message...


The more I learn about managed packages, the more I wish I hadn't changed my package into a managed one.  Salesforce hasn't thought this through very well, and managed packages are too inflexible today.  Not being able to remove items from a managed package, not being able to "unmanage" a managed package, and only being able to create one managed package from a Developer Edition instance make managed packages nearly unusable.  Hopefully there will be improvements in future releases of the platform.
Mike LeachMike Leach

I've noticed since converting to managed that newly installed packages from other Developers automatically add our namespace prefix to their objects and properties. This effectively kills our ability to integrate with others or build on base packages.

We frequently ask clients to upload private packages for review. This scenario now also automatically adds our namespace prefix to their objects.

As a requirement, I would expect only internally created and owned custom objects to be prefixed. I would expect the ability to manage multiple apps, or at least change which app is under management.

This particular DE org is the registered owner of our AppExchange apps and is our identity user on community sites, so abandoning it is not really an option. I too wish I could "undo" our managed status.

Uggggh. :smileysad:


Jim Yu.ax185Jim Yu.ax185
After you release a managed package (by uploading a non-beta package), you will no longer be able to make destructive changes (deleting fields, objects, etc.) to the components that have been released with that package. 

This is to make sure that upgrades do not break for customers (their customizations stay in place and non-of their meta data is removed).  This is also the same way that does upgrades.  For example, once we release an object like Account, we first beta test it with customers in pre-release, and then once we do the release - we cannot remove a released field like Account Name because that would break the customers environments.

You should be able to make destructive changes to your package if that component has only be uploaded in a beta-package.

Also, while you cannot "unmanage" a managed package, you can create an unmanaged package, and add the same components into that package.


Jim Yu
Director of Platform Product Management

As an application developer, I know how the fields, objects, etc. in my application are being used.  I may have a field or object that was being used by external code (via the Salesforce API) but is no longer being used.  Removing this field or object will not break anything for users who have installed my application, so I should be allowed to do so.  Of course there is no way for the platform to know which items can be safely removed, but you should trust application developers to have this level of understanding of their own applications.  Perhaps display a warning if I try to make a "destructive" change to a published application, but let me go ahead and do it if I really want to.

In my case I released an application that includes a custom link for the Product object.  The application was successfully beta tested by several customers.  But after it was released we discovered that some Salesforce Professional instances don't include the Product object.  Our application can't be installed in those instances.  I want to remove this link from the package so it can be installed by these customers.  None of our existing customers are using this link, so making this "destructive" change wouldn't hurt anyone.  But the platform won't let me do this.  And I can't create an unmanaged package to do the same thing because the namespace prefix makes it so external code sees managed and unmanaged objects with different names via the API.

Please trust your developers and give us the ability to remove items from our managed packages!

Mike LeachMike Leach
The requirement to preserve deployed data descriptions is well intentioned. I had hoped managed apps would take more of a versioned approach and enable packages to self-describe their migration paths.
I think a wide range of flexibility could be achieved by adding the following 2 properties to the sForce.Field object:
Field.Archived (bool)
Field.Version (int)
Packages could then contain metadata that maps previous fields to new fields, or archives (but retains) existing fields. Field versions can be paired with object versions.
Another request: Avoid a major/minor representation of Version and opt for an auto-incremented integer (on packages, objects, and fields).

I agree with the with above posts.  I love the upgradability however, in two recent implementations we have found out the hard way that destructive changes are not the only functionalities that have been disabled.  In my humble opinion, changes to the following object attributes do not fit into the ‘destructive changes’ category:

Custom Object Attributes
-  Allow Reports
-  Allow Activities
-  Track Field History
-  Record Name Display Format (Huge - in our sector, Auto Number IDs need to be in a customer specific format)
-  Object Label - Different customers have different terminologies

Custom Field Attributes
-  Field Labels (if changed from a customer’s implementation, subsequent installations should not overwrite the values)
-  Default Value 
-  Increasing field size (Text Fields 50 to text 100).
-  Require Field  (Text Fields)
-  Unique (Do not allow duplicates) (Text Fields)
-  Number Options (Increase only – this one is probably in a grey area)
-  Formula

Custom Button Attributes
-  Window open properties (Size, scroll bars etc… but you can change the URL that it points to?) 

I am sure that I have missed some – I urge other developers to poke around their environments and find more.  I think Salesforce would greatly appreciate the feedback!  Enabling these features for many developers is extremely important – even after our extensive q/a process we’ve had customers request functionality that we can’t deliver on because our packages are out of beta.  Another suggestion I have is Deprecated objects.  I can understand not deleting objects that are in production however, excluding them from new customer implementations would clean things up a bit. 


Thanks for the detailed feedback.

There are several different things going on here:

Object Label and Field Label:  With the current architecture, an attribute may be either developer-controlled, or subscriber-controlled, but not both - because if both can change the field, then it isn't clear what should happen in an upgrade.  So, the developer can change these attributes, but the subscriber cannot (without using Translation Workbench).

Allow Reports, Allow Activities, Track Field History:  These attributes are subscriber-controlled.  Allowing the developer to modify these attributes after release is possible, but it would be somewhat misleading: existing subscribers would not receive the changes.  As a developer, you cannot rely on a subscriber-controlled attribute having a particular value.

Record Name Display Format:  In your particular use case, this should be subscriber-controlled, not developer-controlled.  However, there are scenarios in which the field must be developer-controlled (ie if your app is composite and your external integration relies upon a particular id format).  Again, we had to choose either developer-controlled or subscriber-controlled.

Uniqueness & requiredness: Changing a field from non-unique or non-required is a breaking change - subscribers may have external integrations that assume non-uniqueness/non-requiredness.

Increasing the size of a text field: Unfortunately, this could be considered a breaking change as well - subscribers may have external integrations that assume a certain maximum field length.

Please remember that Winter '07 is the very first version of managed packages and upgrade.  We're aware that the system is currently over-constrained.  Over time, we plan on relaxing the restrictions in some areas as we increase the expressiveness of packaging and upgrade, and our metadata in general.
Mike LeachMike Leach

Customizable labels are a requirement in all our solutions. Are formulas and merge templates the only 2 entities that have dependencies on labels?

Perhaps the long term solution is to support field object names in formulas and merge templates.

For example, a formula for calculating Net Profit/Loss would support both the Label and Object Name syntax:Code:

{!ObjectName.Revenue} - {!ObjectName.Costs}


{!PRFX__ObjectName__c.PRFX__Revenue__c} - {!PRFX__ObjectName__c.PRFX__Costs__c}

Not the most user friendly syntax to look at, I'm sure, but the benefits outweigh the cons.

Customers could then change the labels without impacting the formulas and merge templates and Developers can multi-purpose their base/generic packages.

I'm seeing neither developer nor subscriber control for the the Record Name Display Format. Once the item is in a managed package it is locked for both users. This field should be editable for at least someone. The subscriber does not have the Edit field visible on the Standard Name field, while the Display Format field is uneditable for the administrator.
sorry, my reply should not have been in this thread
I'll have to restate my response:

Regarding the Record Name Display Format field, I'm seeing neither developer nor subscriber control. Once the item is in a managed package it is locked for both users. This field should be editable for at least someone. The subscriber-admin does not have the Edit field visible on the Standard Name field, while the Display Format field is uneditable for the developer-admin.
From my observation, this would seem to contradict your judgement on the Record Name Display Format field.

I have a similar problem

One of our custom objects uses 2 lookup fields to Products and Campaigns [prfx_related_products_c] [prfx_related_campaigns_c]

It was put in there only for ease of reporting and relating our objects to Products and Campaigns.  It does not compromise the integrity of the data if they are deleted.

Our app can no longer be installed by customers using Editions that do not support Products or Campaigns.

I must fix this.  What are my options?

Message Edited by GFlynn on 04-01-2008 07:17 AM

it's a 4 years old problem! I cannot imagine we are still unable to remove fields of package! It's unbelievable that we have to create a new Dev Org (because just one managed package / org...), to import all our stuff just to be able to remove a few useless fields of an old package... What a lost of time....

We have a managed package that is not live yet, and is undergoing a security review.  The package contains an old custom field that I am no loger using and would like to permanently delete from the package (as suggested by the security team). 

  Is there a way to remove the unused fields, since nobody is actually using the package?