Managed package upgrade fail

Software development is always an iterative process and repeatability is key. So multiple deployments to internal or external test teams or to production environments should produce predictable results.

The good news is that a managed package can achieve this for most (but unfortunately not all) parts of a app if fresh installs are done. But in reality managed package upgrades are far more common than fresh installs because they can be done without disturbing existing data: test teams have test data setup and want to log bugs that link to examples of problems; production environments contain (large volumes of) production data. The bad news is that by design the managed package upgrade process chooses to not update layouts and picklist entries. So as an app evolves, layout changes such as new fields or re-arrangements of existing fields or new custom buttons and links are lost by default. And so are new picklist entries meaning functionality based on the new values is also lost by default.

I understand the reason for this approach is that layouts and picklist entries can be edited after they are installed and so an upgrade process that updates will overwrite any local changes and I agree that that would be a bad thing. But based on my experience over the last year with multiple customers, issuing lists of manual update steps and dealing with bugs about fields missing in layouts and values missing in picklists is also a bad thing. And with customers wanting to operate in multiple orgs – development, QA, UAT, production – and work iteratively with updates every one or two weeks the cost (in dollars, in risk to your reputation, and emotional drudgery) of trying to manually keep consistency is large.

I suggest that there are some apps where end-user customization is normal and expected and there are other apps where no customization or more controlled customization (including version control) is normal. For the latter type of app, having a managed package upgrade option to update layout and picklist entries seems like an important and obvious feature.

My attempts to influence salesforce on this directly have failed as have several postings on the ideas forum. If you are a managed package developer or are thinking of becoming one, I urge you to raise this issue with salesforce. Or be prepared to suffer poor quality and high costs for the foreseeable future.


2 thoughts on “Managed package upgrade fail

  1. For those of us with Managed Packages in distribution, is there a set of Ideas that you would suggest we review and possibly support?

  2. Ted,

    Here are ones I found:

    But I don’t think there is any feedback from anyone in salesforce and I take the view that if such feedback is missing then what is being said is effectively not being heard. Supporting such ideas can’t do any harm though…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s