Picklist Values
A picklist value is one of the individual options a Salesforce picklist field offers a user during data entry.
Definition
A picklist value is one of the individual options a Salesforce picklist field offers a user during data entry. Each value pairs a label that people read in the dropdown with an API name that code, formulas, validation rules, and integrations reference. Values can be active or inactive, sorted manually or alphabetically, defaulted, and filtered so different record types show different choices.
Admins maintain these options in two places. Field-specific values live on a single picklist field. Global picklist value set values are defined once and shared across many fields. Where you store and how you manage these options shapes data quality, reporting accuracy, and how cleanly an org scales over time.
How picklist values behave across labels, status, and reuse
Label versus API name
Every picklist value carries two identifiers, and confusing them causes real bugs. The label is the friendly text a user reads in the dropdown, like In Progress or Closed Won. The API name is the stable string that Apex, flows, validation rules, formulas, and external integrations match against. When you create a value, Salesforce derives the API name from the label, but the two become independent after that. You can rename a label without touching the API name, which is the safe move. Renaming the API name is the dangerous one, because anything that hard-codes the old string silently stops matching. Reports filtered on a value, record-triggered flows checking a stage, and middleware mapping rows all break quietly rather than throwing an error. Experienced teams treat the API name as a contract. Decide it carefully at creation, then leave it alone. If the business wants different wording, change the label only. This separation lets the user-facing language evolve while the automation underneath stays stable, which is exactly what you want in an org that many people depend on.
Active and inactive values
A picklist value is not simply present or gone. It has a status, and that status is how Salesforce protects your history. An active value appears in the dropdown and can be selected on new and edited records. An inactive value disappears from the picker but stays attached to any record that already holds it. This is the single most important habit in picklist hygiene: deactivate, do not delete. If you delete a value, you have to decide what happens to records that used it, and you lose a clean audit trail. Deactivating retires the option going forward while preserving what the data meant historically, so reports grouped by that field still show the old value correctly. There is a practical ceiling too. A global picklist value set has a combined limit of 1,000 active and inactive values. Inactive values count against that total and can slow performance when they pile up. Salesforce therefore lets admins manage and bulk delete truly unused inactive values once you are certain no record references them anymore.
Field-specific values versus a global value set
The first design decision is where the values live. Field-specific values belong to one picklist field on one object. They are quick to set up and fine when a list is genuinely unique to that field. The problem appears when the same list, think Region, Industry, or Status, shows up on several fields and objects. Maintaining it in five places guarantees drift, where USA on one field and US on another quietly break a cross-object report. A global picklist value set solves this. You define the values once, then base multiple picklist fields on that shared set. Update the set, and every field built on it updates together. You can keep up to 500 global value sets in an org. There is a tradeoff to know up front. A global value set is restricted by nature, so only an admin can add or change values, and users cannot save off-list entries even through the API. You also cannot promote an existing field into a value set, and the association is hard to unwind. Choose deliberately, because the decision does not reverse easily.
Record types and value filtering
Picklist values do not have to be all-or-nothing across an object. Record types let you show a tailored subset of the same field values to different audiences. A single Lead Status field can expose one set of stages to the inside sales team and a different set to the partner team, driven entirely by record type. The full list of values still lives on the field. The record type simply decides which of those values are available and which one is the default for records of that type. Short, relevant dropdowns cut data-entry errors and speed up users. It matters when you add a new value too. Salesforce asks whether to add that value to the record types that use the field, so a fresh option does not silently fail to appear where a team expects it. Pairing record-type filtering with a global value set is a common pattern in mature orgs. The shared set guarantees one source of truth, while record types control context. You get consistency and relevance at the same time, without duplicating the underlying list.
Dependent picklists and controlling fields
Some picklists should narrow based on another choice. A dependent picklist filters its available values according to the value selected in a controlling field. Pick United States as Country, and the State picklist shows only US states. The controlling field can be a standard or custom picklist or a checkbox, and the dependent field is always a custom picklist or multi-select picklist. You define the relationship in a filter matrix, mapping which dependent values are valid for each controlling value. Done well, this prevents nonsense combinations at the point of entry, which beats catching them later with a cleanup script. There are bounds to respect. A controlling picklist used in a dependency is limited to 300 values, and any one value can control up to 300 dependent values. Dependencies also do not enforce themselves through every path. A user with the field missing from a page layout, or a record created by an integration, can still produce a pairing the matrix would not allow. Treat dependencies as guidance for clean entry, and back any rule the data must truly hold with a validation rule.
Sorting, defaults, and reporting impact
Order is not cosmetic when a field drives reporting. You can sort picklist values alphabetically or arrange them manually, and the choice changes how people work and how charts read. Process stages usually want a deliberate manual order, so New, Working, Escalated, Closed reflects the real flow rather than an alphabetical accident. Reference lists with no natural sequence often read better alphabetically. You can also set a default value so the most common choice is pre-selected, which trims clicks and nudges users toward consistent data. Every one of these settings flows downstream into reports and dashboards. The value label is the group-by key, so a stray duplicate like Closed Won and Closed-Won splits one bucket into two and quietly distorts totals. Consistent, well-ordered values with stable API names keep summary reports honest and make formulas predictable. The discipline is small but compounding. Spend a few minutes naming and ordering values correctly at creation, and you avoid hours later untangling reports that disagree because the options drifted apart.
Translation, multi-select, and other edges
A few details surface once an org grows beyond a single team or region. Picklist labels are translatable through the Translation Workbench, so French users can see Clos Gagne while the API name stays Closed Won for every formula and integration. That keeps automation language-neutral while the dropdown reads naturally in each locale. Multi-select picklists let a user pick several values at once, but they behave differently in reporting and formulas, and a single multi-select field allows up to 500 values with a default selection cap to respect. Treat them as a tool for genuinely many-valued data, not a default. Standard picklist fields that ship with Salesforce, like Opportunity Stage or Case Status, often map to extra behavior such as forecast categories or closed flags, so editing their values can ripple into features you did not expect. Read the field documentation before changing a standard picklist. New custom values are the low-risk place to experiment, while standard ones reward a careful, tested change in a sandbox first.
How to add a value to a picklist field
Adding a value to an existing custom picklist field is one of the most common admin tasks. The steps below add a new active value, place it in the right order, and make sure it shows up for the record types that need it. Always make the change in a sandbox first when a standard field is involved.
- Open the field in Object Manager
In Setup, go to Object Manager, choose the object, open Fields and Relationships, then select the picklist field you want to edit.
- Add the new value
In the Values section (or Values Set for a global set), click New, type one value per line, then save. Salesforce derives the API name from the label.
- Choose record-type assignment
If the field is used by record types, Salesforce asks which record types should include the new value. Select the ones that need it so the option actually appears.
- Set order and default
Use Reorder to place the value in a sensible position, choose alphabetical or manual sorting, and set a default value if this field should pre-fill a common choice.
- Verify and test
Open a record of each affected record type, confirm the value appears in the dropdown, and check that any dependent picklist matrix or validation rule still behaves as expected.
Display the list alphabetically or in a manual order. Use manual order for process stages so they read in real-world sequence.
Pre-select the most common option to cut clicks and steer users toward consistent data entry.
Block users and the API from saving off-list values, which a global value set enforces by nature.
Decide which record types include the new value so it appears for the right teams and not others.
- A new value will not show up if you skip the record-type assignment prompt, even though it exists on the field.
- Renaming a value label is safe, but changing its API name breaks flows, formulas, and integrations that reference the old string.
- Deactivate values you no longer want rather than deleting them, so historical records and reports stay accurate.
- Editing values on a standard picklist like Opportunity Stage can affect forecast categories and closed logic, so test in a sandbox first.
Prefer this walkthrough as its own page? How to Picklist Values in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Create a Global Picklist Value SetSalesforce
- Dependent Picklist ConsiderationsSalesforce
Straight from the source - Salesforce's reference material on Picklist Values.
- Dependent PicklistsSalesforce
- Manage Inactive Picklist ValuesSalesforce
Hands-on resources to go deeper on Picklist Values.
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. What are Picklist Values in a Salesforce picklist field?
Q2. How does record-type filtering interact with the Picklist Values on a field?
Q3. What is the clean way to retire a Picklist Value that historical records are still using?
Discussion
Loading discussion…