So, a classic situation came up today. A colleague created a picklist on Quote and then needed that same picklist on Opportunity. What did they do? Created another field manually and typed every value again. Same name, same values, two different places to maintain.
Does it work? Sure. But when someone requests a new value or a label change, you have to remember to open every object and repeat the update. Miss one field and the data can quietly drift out of sync.
That is when I asked: why not use a Global Value Set? Let’s unpack it.
What is a Global Value Set?
A regular custom picklist belongs to a specific object. It is created as a field on that object, and its values live there.
A Global Value Set (also called a Global Picklist Value Set) works differently. As the official documentation explains, it exists independently of individual objects. Every picklist field created from that set shares the same values.
Think of it this way: instead of each object keeping its own list, you have one central list, and the fields reference it.
Global Value Set: Sales_Channel
├── Quote.Sales_Channel__c
└── Opportunity.Sales_Channel__c
Change the central list, and the change reaches every field that uses it.
Why it is worth using
When the same list of values is needed on more than one object, a Global Value Set makes life easier:
- Maintain it in one place. Update values in the Global Value Set and those changes apply to every field that references it.
- Keep objects consistent. When values move between objects, such as Quote and Opportunity, you avoid maintaining two slightly different lists.
- Protect allowed values. Global Value Sets are restricted by design. Only an administrator can add or change their values, and values outside the set cannot be written, even through the API.
- See where the set is used. The Global Value Set detail page includes Fields Where Used, listing every field that references it.
Look closely at that second point. If one field uses an accented label and another uses an unaccented version, copying values between objects can become a headache. One central set prevents that particular mismatch.
How to create and use one
There are two stages: create the central value set first, then create fields that reference it.
1. Create the Global Value Set
- In Setup, type Picklist into Quick Find and select Picklist Value Sets.
- Next to Global Value Sets, click New.
- Enter a Label. This is the name shown when someone creates a field.
- Write a clear Description explaining the purpose of the values and which objects use the set.
- Enter the values, one per line.
- Optionally, choose alphabetical sorting and/or use the first value as the default.
- Click Save.
2. Create a field that uses the Global Value Set
- In Setup, open Object Manager and choose an object, such as Quote.
- Select Fields & Relationships, then New.
- Choose Picklist and click Next.
- Enter the Field Label.
- Under Values, keep Use a global value set selected and choose the set you created.
- Complete field-level security and page layout settings as usual, then save.
Now repeat only step 2 on Opportunity. You do not need to type the values a second time.
One useful detail: each field can have its own default value, independent of the Global Value Set default. That includes formula-based defaults.
Important considerations
Before making every picklist global, keep these documented rules in mind:
| What | Rule |
|---|---|
| Picklist type | Always restricted. It cannot be converted to unrestricted. |
| Values per Global Value Set | Up to 1,000, including active and inactive values. |
| Global Value Sets per org | Up to 500. |
| Fields that use one value set | No fixed limit. |
| Used on more than 13 objects | Values can still be deactivated, but they can no longer be replaced or deleted. |
| Field association | The association cannot be undone. To use another value set or independent values, the field must be deleted and recreated. |
| Deleting a value | A background job processes the deletion and sends an email on completion. |
| Record Types | When adding values, you can make them available to all Record Types that use the set. Otherwise, update Record Types manually. |
The field association is the tricky part. Before creating the field, ask yourself: might this object someday need a value that makes no sense on the other object? If so, a global set might not be the best choice.
Also remember that changes to a Global Value Set affect every field that uses it. Centralization is great, but a careless replacement can change data across several objects at once.
What if the picklist already exists?
Sometimes you do not realize a list will be reused until later. That is what Promote to Global Value Set is for: it turns the values from an existing field into a shared value set.
- Open Fields & Relationships on the object containing the picklist.
- Click the picklist Field Label.
- Click Edit.
- Click Promote to Global Value Set.
- Enter a label and, optionally, a description for the Global Value Set.
- Click Promote to Global Value Set again.
From there, Trailhead recommends using the newly promoted set when creating another picklist field.
For those who work with metadata: the corresponding metadata type is GlobalValueSet, with .globalValueSet files in the globalValueSets folder. One more detail: Global Value Sets created starting with API version 57.0 automatically receive the __gvs suffix in their developer name, and that suffix must be included in fullName for CRUD-based calls.
Wrapping up
In today’s example, there was nothing inherently broken about creating the second field manually. It works. But using a shared value set is a good practice that can prevent rework and data inconsistencies later.
Here is the simple decision question:
Will this same list of values be used on more than one object, or will values be copied between objects? If yes, create the Global Value Set first, then build the fields. If not, a regular picklist offers more flexibility.
