Master Picklist
A master picklist in Salesforce is the complete, field-level list of values that a picklist field can hold.
Definition
A master picklist in Salesforce is the complete, field-level list of values that a picklist field can hold. It is the single source of truth for that field. Every record type on the object draws from this master list, exposing a subset of its values rather than defining its own separate set. The master picklist is independent of all record types and business processes, which is why a value has to exist in the master before any record type can show it.
The idea matters because picklist administration runs on two layers. One layer is the master, which answers the question of what values are possible at all. The second layer is the record type, which answers which of those values a given record type displays. Mixing up the two layers causes a lot of avoidable mistakes. Add a value only to the master and no user sees it. Remove a value from the master and it disappears from every record type that included it.
How the master picklist controls every record type
Master values versus record-type values
The master picklist holds every value the field can ever store. Each record type on the object then configures which of those master values it makes available to users. A value cannot appear on a record type unless it already exists in the master. This is a strict parent-child relationship: the master is the parent set, and each record type is a filtered child of it. When you create a new record type without cloning an existing one, Salesforce automatically includes all the master picklist values for both standard and custom picklists. From there you trim the list down to what that record type needs. The reverse direction also holds. If you remove a value from the master, it is no longer available when creating records, and it drops out of every record type that included it. Records already assigned the removed value keep that value and are not changed. This split lets one object serve very different processes. A Case object might expose a Returns status set on one record type and an Escalations status set on another, both sourced from the same master. The master defines the universe of values; record types decide who sees what.
Adding a value the right way
Adding a picklist value is a two-step job, and skipping the second step is the most common picklist mistake admins make. First, edit the field and add the value to the master picklist. At this point the value exists, but no record type displays it, so users still cannot pick it. Second, enable the value on each record type that should show it. You do this from the record type's picklist edit screen, moving the value from Available to Selected. If the field uses a global value set, Salesforce offers a shortcut. When you add new values to the global set, you can check a box labeled to add the new values to all record types that use that value set. Without that option you add the new values to each record type by hand. The lesson is simple. The master controls whether a value can exist, but record-type configuration controls whether anyone actually sees it. Test the change by opening a record of each affected record type and confirming the new value appears in the dropdown before you call the work done.
Deactivating, removing, and replacing values
Retiring a value has three different paths, and choosing the wrong one can damage data. Deactivating a value takes it out of the dropdown for new entries while leaving every existing record untouched. Old records keep displaying the value, and reports still group on it, but users cannot newly select it. This is the safest retirement path. Removing a value from the master is more aggressive. The value stops appearing when creating records, though records already assigned to it are unchanged. Replacing a value is a global operation that rewrites the value on all existing records, including those in the Recycle Bin, and it updates the Modified By date and time on every affected record. Replacing also strips the old value out of any report filter criteria that referenced it, which can silently change report results. Because of these side effects, deactivate first when you are unsure, watch how the value behaves over a release or two, then remove or replace it only once you are confident nothing depends on it. Document the change so teammates know why a value vanished.
Global value sets as a shared master
A global value set is a named list of picklist values defined once and reused across many fields and objects. It sits a level above the field-level master. When a picklist field is based on a global value set, that field no longer keeps its own private list. Instead it inherits values from the global set, and you can only change those values by editing the global set itself. Any edit there flows to every picklist that inherits from it, which is exactly what you want for shared concepts like Country, Region, or a standard Status ladder. A global value set is restricted by nature. Only an admin can add or change its values, and users cannot enter unapproved values, even through the API. There is a scale limit worth knowing. If you apply a global value set to more than thirteen different objects, you can still deactivate values, but you can no longer replace or delete values from the set. For a one-off picklist used on a single field, the field-level master is enough and a global set is unnecessary overhead. Create a global value set in Setup under Picklist Value Sets.
Sort order, default value, and labels
Several display settings live on the master, and a few deliberately do not. The master controls the default sort order of values in dropdowns, and record types inherit that order unless an admin overrides it. The default value, meaning the value pre-filled on a new record, is set per record type rather than on the master. Two record types can therefore start new records on different defaults while sharing one master list. Importantly, changing the default value on the master does not change the default value already configured for any record type. Each picklist value also carries two identities. The label is what users see in the interface, and the API name is what code, formulas, flows, and integrations reference under the hood. Renaming a value updates only the label and leaves the API name untouched, so sharing rules, formulas, flows, and Apex keep working. That makes relabeling safe. It does have one quiet side effect: renaming a value removes it from any report filter criteria that used the old label, so audit your reports after a rename.
Restricted picklists and data quality
A picklist field can be marked as restricted. When it is, users and integrations cannot store any value that is not on the master list. An attempt to write an off-list value through the API fails with a bad value for restricted picklist field error rather than quietly saving. This is the behavior most production picklists want, because it keeps the field clean and makes reporting reliable. Without the restricted setting, the field is more forgiving. A value written through the API that is not on the master can still be stored, and it then shows up as a stray entry that pollutes reports and dashboards. The unrestricted mode exists mainly for data migration, where you may need to load historical values that do not yet match the curated master, or for fields where an open-ended capture is intentional. The practical guidance is to make production picklists restricted once the value list has stabilized, and to reserve unrestricted behavior for the narrow cases that genuinely need it. Pair a restricted master with deactivation rather than deletion, and the field stays both clean and auditable over time.
Why this concept trips people up
Most picklist confusion comes from forgetting which layer an action touches. New admins edit a record type, do not see their value, and assume the platform is broken, when really the value was never added to the master. Others add a value to the master, see it in one record type, and assume it is live everywhere, when other record types still need it enabled. Deployment adds another trap. When you move a record type between orgs using a change set, Salesforce does not automatically pull in the dependent picklist field, so the available values and the default value can arrive empty unless you add the picklist field to the change set as an explicit dependency. Keeping the mental model straight solves most of this. The master answers can this value exist. The record type answers does this audience see it. The restricted flag answers can anyone store an off-list value. The global value set answers do multiple fields share one curated list. Hold those four questions in mind and picklist administration becomes predictable instead of a guessing game across Setup screens.
How to add a value to a master picklist and expose it on record types
Adding a value to a master picklist and exposing it on the right record types is a two-stage task. Stage one edits the field-level master. Stage two enables the value per record type. Here is the path in Setup for a custom picklist field.
- Open the field in Object Manager
From Setup, go to Object Manager, pick the object, open Fields and Relationships, then open the picklist field you want to edit.
- Add the value to the master
In the Values section, click New, type the new value (one per line if adding several), and save. The value now exists in the master but no record type shows it yet.
- Enable the value on each record type
Open each relevant record type, edit its picklist assignment for this field, and move the new value from Available Values to Selected Values. If the field uses a global value set, you can instead choose the option to add the value to all record types that use the set.
- Confirm sort order and restricted setting
Set the default sort order on the field if needed, and confirm the field is marked Restricted for production so off-list values cannot be stored.
- Verify on a real record
Create or edit a record of each affected record type and confirm the new value appears in the dropdown before considering the change complete.
When enabled, blocks any value not on the master, including writes through the API. Recommended for production fields once values stabilize.
Bases the field on a shared, admin-only value list reused across fields and objects. Edit values only on the global set; changes flow to every field that inherits it.
Controls how values appear in dropdowns. Record types inherit this order unless overridden. Choose entered order or alphabetical.
Set per record type, not on the master. Changing the master default does not change a record type default already configured.
- Adding a value only to the master, then forgetting to enable it on record types, is the top reason a new value does not show up.
- Removing a value from the master drops it from every record type, though records already assigned to it keep the value.
- Replacing a value rewrites it on all records including the Recycle Bin and strips it from report filters that referenced it.
- When deploying a record type via change set, add the dependent picklist field explicitly or the available values and default value can arrive empty.
Prefer this walkthrough as its own page? How to Master Picklist in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Master Picklist.
- Create a Global Picklist Value SetSalesforce
- GlobalValueSet | Metadata API Developer GuideSalesforce
Hands-on resources to go deeper on Master Picklist.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. An admin adds a value to a picklist field's Master Picklist, yet no record type shows it to users. Which step was skipped?
Q2. When a value is deactivated on a Master Picklist rather than deleted, what happens to the existing records?
Q3. How does marking a picklist field as Restricted change the behavior of its Master Picklist?
Discussion
Loading discussion…