Global Picklists and managed packages

Today I want to talk about Global Picklists, a feature that was made GA in Winter 17. Global Picklists allows you to share picklist values among different objects. They can be very useful in certain use cases. For example, imagine that your company gives support to several countries. You can create a global picklist that holds the supported countries, and use it in many objects in your application. Then, if you need to add a new country, you will need to do it only once.

Additionally, in this post, I will give some information about Global Picklists behaviour in managed packages.

Screen Shot 2017-07-28 at 13.21.19

First of all, let’s see how to define a Global Picklist. This is very simple, you just have to navigate to “Picklist Value Sets” in the setup, and define a new Global Value Set:

 

Screen Shot 2017-07-28 at 13.21.30

Once you have created the Global Value Set, you will have to add some values. Also you can select the default value and assign some chart colors:

Screen Shot 2017-07-31 at 14.34.32

Then, if you create a new picklist or multiselect picklist field for any object, you will have the option to use a global picklist value set, instead defining a new set of values:

Screen Shot 2017-07-31 at 14.36.32

One thing to bear in mind is that if your picklist field uses a Global Picklist, its values will be restricted by default to those in the global value set. However, you can edit / delete / deactivate or add new values in the global value set, even if it is managed.

Then, how do global picklists behave on managed packages?

Global picklists can be packaged and distributed to your customers. If you want to package a Global Picklist, you have to look for “Global Value Set” in the components drop-down, and select the one that you want to package:

Screen Shot 2017-07-28 at 13.22.03

If you have installed a package that contains a managed Global Picklist, you can use the global value set on any object in your organization, even if belongs to a different namespace.

As we said before, you, or a subscriber, can edit / delete / deactivate or add new values in the global value set, even if it is managed.

What would happen if we modify the global picklist values in the package, and the subscriber performs an upgrade?

Well, Global Picklists behaviour, in this sense, is different than normal picklists. If existing values were changed or deactivated in the subscriber org, they won’t be restored to their original state on upgrades. However, new values will be added on upgrades.

Last note: bear in mind these limits if you are going to use Global Picklists:

You can have up to 500 picklist global value sets in an org. Each global value set, or restricted picklist, can contain a mix of 1,000 active and inactive values. Unrestricted picklists can have up to 1,000 active values. There’s no limit on the number of custom picklists that use global picklist value sets.

Edit Spring 18: The behaviour of global value sets has changed. Now:

  • Label and API names for individual values don’t change in subscriber orgs. 
  • New values aren’t added to the subscriber orgs.
  • Active and Inactive value settings in the subscriber orgs don’t change.
  • Default values in the subscriber orgs don’t change.
  • Global value set label names change if the package upgrade includes a new label value.

4 thoughts on “Global Picklists and managed packages

  1. Hi,
    I try to retrieve GlobalValueSet in API 41 but color isn’t appear in the CustomValue metadata. Any idea?

    Like

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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