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.
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:
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:
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:
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:
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.
Reblogged this on Chris Neudecker is helping you learn and commented:
Great article for SFDC
I try to retrieve GlobalValueSet in API 41 but color isn’t appear in the CustomValue metadata. Any idea?
Color is not an attribute of global value set, as you can see in the docs: https://developer.salesforce.com/docs/atlas.en-us.210.0.api_meta.meta/api_meta/meta_globalvalueset.htm What are you trying to achieve exactly?