One of the most voted ideas in the Salesforce IdeaExchange forum was to be able to create a picklist that can be shared across objects.
Salesforce delivered the idea in pilot as of Winter ’16, and is now in Beta for Spring ’16. If you look at the release notes, you would find it by the name ‘Global Picklists”. It is also referred to as Universal picklists.
This could be one of the most exciting features for Salesforce customers, as often you see cases for having the same picklist replicated on multiple objects. Some examples are Zip code picklists, Sales territories, Product picklists, Competitors, Business Lines. Maintaining these picklists across a large implementation is usually a painful and error prone task.
Global picklists allow administrators to create a centrally defined list of values, which can be applied to any custom picklist fields that you create – both on standard and custom objects. This makes maintenance of picklists values easy, as now administrators only need to make the updates centrally.
To see how Global Picklists work, lets look at an example of an organization that has multiple business units. These business units need to be represented on Leads, Accounts, Contacts and a custom object – Expense.
To setup a Global Picklist that can be used in all of these objects, As of Spring ’16, you would navigate to the Setup screen and search for “Picklists” to find the Global Picklists set up screen.
For our example, you would define a global set of picklist values with the name ‘Business Units’. The UI and definition of the values is very similar to how you would set values during the creation of a regular custom picklist field – only that here, you are simply creating an ordered set of values, and not a field.
Now, you have a centrally defined set of global picklist values which represent the organization’s business units. You would then navigate to the Leads, Account, Contact and all other relevant objects to create custom picklist fields.
While creating the custom picklist fields on an object, you would now notice the new option to select whether the picklist should be based on any global picklist values. In our case, we have a global picklist already created, and therefore we associate it. The remaining field creation process is unchanged, and you would proceed to set up the field visibility and page layout definitions. The same process is repeated on as many objects as required.
Global Picklists are Restricted Picklists by Default
One important aspect regarding using Global Picklists is that, they are treated as restricted picklists by default. The Restricted picklist feature is yet another Winter ’16 feature – which allows administrators to specify whether end users can add new picklist values via the API. Currently a value can be added to a picklist field via the API (e.g. DataLoader) but it will not be added to the defined list of picklist values. This feature was brought in to provide means for administrators to enforce data integrity – by making sure that users only import and add clean data that is consistent with the already defined picklist values.
As seen in the image above, while using a global picklist definition to create a picklist field, the “Strictly enforce picklist values” option remains checked and greyed out.
See more about restricted picklists here: Restricted Picklists described in Release Notes
And here is our Global Picklist in action:
- Validation rules are still defined at the field level, and are not part of the global picklist definition. This means, you can have the Business Unit picklist field on Account to respect a validation rule; and the same field on the Contact object not.
- It is possible to create a mutli-select picklist field using a global picklist definition. However, in such cases the ‘replace’ functionality available on regular picklist fields are not available.
- Also, a picklist field created based on a global picklist cannot be used as a dependent picklist. It can still be used as a controlling picklist field. This is a known and documented limitation.