While trying to figure out how to best manage my objects, using managed packages was suggested. I think this has a lot of potential, but was wondering at what point should one switch customizations over to a managed package?

For a concrete example, our main app has about ten custom objects, half a dozen related lists, over 100 custom fields on the Opportunity plus all of the supporting validation rules and workflows. Would this be a good candidate for a managed package? Why or why not?

  • I manage a much bigger Salesforce implementation. I use eclipse with the Salesforce plugin. It works well. I've tried packages before but found them to only work well for small (or localized) changes. Rather than use two approaches for managing the environment, I simply use eclipse for everything. Try either approach in a sandbox to get a sense for how they work. Commented Aug 4, 2012 at 12:57

3 Answers 3


Managed packages are really intended for distributing code outside of your own organization. A managed package includes a significant set of deployment and license management features. But, a managed package also places a number of restrictions on what can be done with the package between releases. It's not a lightweight option.

An unmanaged package might help to organize your components, but it's not a good way to distribute updates.

The more likely solution might lie in using change sets, and then cloning it for future updates, and using the change set to define your "package".


  • 2
    Note that there are a lot of restrictions around the declarative parts of managed packages. You can never remove a custom object or field once it has been included for exaple. Picklist values added in a newer version of the package will not automatically show up for existing customers that upgrade, and the same thing with page layouts. As mentioned the strengths of them come into play when apex is involved, I wouldn't really recommend them for declarative work. Commented Aug 6, 2012 at 4:44
  • 1
    Debugging an installed managed package can be a nightmare. Calls to System.debug are hidden, as are stack traces in exceptions unless you are using LMA (License Managing Application). Your IP is protected, but you can't debug easily. This is especially problematic for Beta managed packages. Commented Aug 6, 2012 at 9:41

Managed packages are a massive hassle. Having been through dozens and dozens of implementations, and several managed package implementations, I only recommend using managed packages when you need to deploy to somewhere and guarantee the installing org will not have access to source code. This mostly applies for AppExchange apps. If you don't have this requirement, managed packages are much much much more hassle than they are worth.

The toolset for packages is really the bare minimum needed for AppExchange developers. Release packages impose very strong restrictions on future changes (e.g. can't rename or remove lots of things), but beta packages can only be installed in sandbox/test orgs, AND they require an uninstall first. This is the main reason that MP's are annoying, but there are many others: namespacing is under-implemented, code sharing between packages is annoying, salesforce imposes an odd limit of N (I think 10) namespaces being called per context, the management of package components is much more difficult than non-package, you can only create one managed package per developer org, etc. Basically not designed for the use case you mentioned and should be avoided at all costs if you don't need to hide your source code and/or install via AppExchange or TrialForce.

I manage all custom codebases by unmanaged packages with package.xml files, deployed between environments using the (Ant) Force.com Migration Tool with a set of convenience batch files for backing up, timestamping, version control, etc. It's a much easier way to go. Changesets would be a close second. I don't recommend managing deployment with Eclipse because IME it's not 100% reliable and is prone to mistakes when you have multiple people updating the source org simultaneously.

  • Any chance you can elaborate on "salesforce imposes an odd limit of N (I think 10) namespaces being called per context". I've never heard of this before (although it certainly sounds like something salesforce would do). Commented Aug 6, 2012 at 4:46
  • 2
    It's another head-scratcher, see salesforce.com/us/developer/docs/apexcode/Content/… - "In a single transaction, you can only reference 10 unique namespaces."
    – jkraybill
    Commented Aug 6, 2012 at 5:56
  • Wow, that sounds like a great way to backdoor limit the number of sales-related appexchange apps you can install into unlimited edition. Good to know, thanks. Commented Aug 6, 2012 at 17:41

One of the considerations for packages is if you need to preserve the data when deploying updates - if the answer is yes then you should go for managed package. With unmanaged packages, there is a potential for data loss.

  • here is a link that describes managed vs. unmanaged packages: wiki.developerforce.com/page/An_Introduction_to_Packaging
    – kadmin
    Commented Aug 4, 2012 at 17:43
  • 1
    Outside of destructive changes or changing field data types, why would the Migration Tool or IDE invite data loss? What does a package do to mitigate that?
    – Mike Chale
    Commented Aug 4, 2012 at 18:48
  • @MikeChale - I was just commenting on the managed/un-managed package. Your understanding about migration tool/IDe is correct.
    – kadmin
    Commented Aug 5, 2012 at 1:48
  • 2
    @LVS when upgrading from one unmanaged package to the next version you must first uninstall the current version and then install the next version. As such, any custom objects or fields you have created will be removed during the uninstall. You would need to manually merge the backup data that is created during the uninstall back in after installing the new unmanaged package. Commented Aug 5, 2012 at 20:32
  • 1
    If correct about data loss then this is an excellent reason to use managed packages! +1 Asking customers to save all data, uninstall and re-import is not an acceptable upgrade path.
    – Marc
    Commented Mar 18, 2013 at 9:09

You must log in to answer this question.

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