13

One of the issues that we always see when creating new releases of our managed package is that new or changed picklist values don't deploy when someone upgrades our app using a new release that we just cut. We have to provide instructions on going into the object and updating the picklist values manually.

How are other managing this? Is there a better way? Am I missing something?

5

Sadly, I don't think you are missing anything - when I have asked SF folks, they view this is a feature because customers can update the lists themselves, and these updates should not be overridden by a package update.

There are some ideas on the exchange about having an option in a package to enable picklists to be always overridden, but for now, manual updates are the only option I know of...

1

The solution we came up with is really a non-solution. Essentially, we roll our own on VF pages and use the captured values to update the picklists. That way, we can add anything we want using Apex/VF. Because the underlying picklists don't care what value you set to them, we can write whatever we capture from the selectLists to them.

This is obviously just for VF pages so there really isn't an elegant solution for standard UI.

1

We "manage" this (and the smilar issue of layouts not updating) by building lists of manual changes to apply in our issue tracking system and lots of tedious (an error-prone) manual work.

While it may be possible to build your own tools that make use of the metadata API to apply updates, given that this is a problem that affects all of us creating managed packages some movement by salesforce in this area would make more sense. My viewpoint on the subject: Managed package upgrade fail.

1

It seems at this time the best approach is to use the Metadata API and place an external API call.

Obviously this is a poor, and sometimes unavailable approach as you may not have access to an org if in a package.

1

we're working as the implementation partner for an isv and they have the admin accounts for all of their customers (more than 1500 orgs). so we implemented a tool that takes a list of admin accounts and a metadata package and pushes the changes via metadata api that cannot be applied by a package update to the customers. this works pretty well but can only be used in the specific scenario that the vendor owns that admin accounts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.