--- title: "Global value sets and picklist governance" url: "https://trailassembly.com/global-value-sets/" topic: "Admin and Permissions" published: "2026-09-21T11:45:36+00:00" updated: "2026-09-23T09:11:26+00:00" --- # Global value sets and picklist governance **Briefly:** a global value set is one list of picklist values shared by many fields, so “Country” means the same thing on five objects and you change it in one place. Use one wherever the same list appears twice. The cost is that you cannot reorder or restrict values per field as freely as with a local set, and converting an in-use local picklist to a global one is a one-way door you should plan rather than discover. ## What you actually get | | Global value set | Local (field-specific) values | | --- | --- | --- | | Defined in | Setup → Picklist Value Sets | On the field itself | | Shared across fields | Yes, any number | No | | Add a value everywhere | One change | Once per field | | Per-field value subset | Yes, choose which values are available | N/A | | Per-field ordering | Inherited from the set | Free | | Max values | 1,000 per set | 1,000 per field | The per-field subset is the feature that makes global sets usable in practice. A global “Status” set can hold every status any object uses, with each field enabling only the ones that apply. You get one vocabulary and per-field relevance. ## When a global set is clearly right - **The same list exists on more than one object.** Country, region, industry segment, product line, currency-like codes. - **Reporting joins on the value.** If a report groups records from two objects by the same concept, divergent spellings make the report wrong rather than untidy. - **An integration maps the values.** One list means one mapping table instead of five that drift. The drift is the real argument. Two local picklists that started identical will not stay identical, because adding a value to one is a thirty-second change nobody thinks to repeat elsewhere. Six months later a report has “EMEA” and “EMEA ” and nobody can explain the two rows. ## When a local picklist is fine One field, one object, values that mean nothing anywhere else. A global set for a list used once adds a Setup object to maintain and buys nothing. Also local: anything where per-field ordering genuinely matters to users, since ordering comes from the set. If sales want their stage list in one order and service want theirs in another, a shared set will annoy one of them. ## The conversion, and why to plan it Converting an existing local picklist to a global value set is supported through the “Promote to Global Value Set” option on the field, and once done, the field’s values come from the set. What to know before you do it: - **Existing record data is not changed** — the stored values stay as they are. If a record holds a value the new set does not contain, you have an inactive-value situation to clean up. - **It is not casually reversible.** Treat it as one-way and do it in a sandbox first on a copy with real data. - **Dependent picklists need re-checking.** Controlling-field relationships are defined per field, and converting the controlling or dependent field means revisiting the dependency matrix. - **Record types filter values separately.** A record type’s available values are a further filter on top of the field’s, so after conversion you have three layers (set, field subset, record type), and all three need to agree. That three-layer filtering is where most post-conversion confusion comes from. A value that exists in the set, is enabled on the field, and is not in the record type’s list, simply does not appear, and Setup does not tell you which layer excluded it. ## Governance that keeps the list usable **Name the set for the concept, not the object.** `Region`, not `Account_Region`, or the second object to use it will look wrong. **Deactivate rather than delete.** Deactivating keeps existing records readable and stops new use. Deleting a value that records hold leaves data referring to something that no longer exists in the metadata, and reports and integrations handle that badly. **Keep API names stable and meaningful.** The label can change. The API value is what integrations and formulas depend on. Setting label and API value independently at creation, rather than letting the value be derived from a label somebody will rewrite, saves a migration later. **Decide who owns the list.** A shared list with no owner accumulates values from whoever needed one this quarter. One named owner per set, and a request process, is the whole of picklist governance. **Watch the restricted setting.** A restricted picklist rejects values not in the list, including via the API. That is usually what you want (it is the thing that actually prevents drift), but turning it on for a field an integration writes to will start failing that integration the moment it sends something unexpected. Check what the API has been sending before you restrict. ## Frequently asked ### How many values can a global value set hold? Up to 1,000 entries, and there is a limit on how many global value sets an org can have. Both are generous enough that hitting them usually signals a modelling problem — a list of 800 values is probably a lookup to an object. ### Can two fields use the same set with different defaults? Yes. The default value is a per-field setting, as is which subset of values is available. Only the master list and its ordering are shared. ### Does a global value set work for multi-select picklists? Yes, multi-select picklist fields can be based on a global value set in the same way. ### What happens to reports when a value is deactivated? Historical records keep the value and still report on it. New records cannot be set to it. That is exactly why deactivation is preferable to deletion. ### Can I convert a global value set back to local values? Treat this as not available. Plan the conversion to global as a decision you are making permanently, which in practice means testing it in a sandbox with production-shaped data first. --- *Reference: Picklist Value Sets*, *Manage Picklist Values* and *Considerations for Changing Picklists*, Salesforce Help. --- Source: https://trailassembly.com/global-value-sets/ Trail Assembly — independent Salesforce write-ups.