Straight answer: the label a user sees and the value stored in the database are two different things, and every picklist problem that survives more than a day comes from that gap. Manage shared lists as global value sets, make anything referenced by automation restricted, and never assume that renaming a value changed what is in your data.
Label and API name
Each picklist value has a label and an API name. The label is what appears in the UI and in reports, and it is translatable. The API name is what is stored on the record, returned by SOQL, compared by ISPICKVAL, and matched by a data load.
That asymmetry is useful. Renaming a label is safe, because nothing behind it changed. Changing an API name is not, because every stored record, formula, flow filter, report filter and integration mapping that used the old one is now wrong, and there is no automatic fixup.
So the trap is not renaming. It is assuming that because the UI changed, the data changed too.
Global value sets
A global value set is one list of values reused by many picklist fields. Setup, then Picklist Value Sets.
What you give up: a field using a global value set cannot have field-specific values added to it, and the field’s values are controlled centrally. Record types can still restrict which of the set’s values are available per record type, so you retain per-context control without duplicating the list.
Restricted and unrestricted
A restricted picklist accepts only its defined values. Anything else, from any source, is rejected.
An unrestricted picklist accepts values that are not in the list when they arrive through the API. The record saves, the value is stored, and the value does not appear in the list. This is how a picklist ends up with “Closed Won”, “closed won”, “Closed-Won” and “CLosed Won” in the data while Setup shows one value.
To convert an unrestricted picklist to restricted, every value present in the data must exist in the value set. The platform will tell you when it does not. Clean the data first with a report grouped by the field, which is the fastest way to see what is actually in there.
Deactivating a value that records use
Three separate operations, and they do different things.
Deactivate. The value stays on every record that has it. It cannot be selected for new records. It still appears in reports, and it still matches filters. This is the right choice when you want to stop new use but keep history intact.
Replace. The Replace action takes an old value and a new one and rewrites every record. It runs in the background, it can take a long time on a large object, and it does not fire validation rules or automation on the records it changes, which is usually a relief and occasionally a problem if you were relying on a trigger to keep another field in step.
Delete. Deleting a value prompts you to replace it or blank it out on existing records. Blanking is data loss with no undo.
Dependent picklists and record types
A record type restricts which values of the field are offered. A dependent picklist restricts based on a controlling field. Both filters apply, and the intersection can be empty, leaving a user with a required field offering nothing. Test each record type against each controlling value before releasing a change.
Scale
Long picklists are a design smell. Once a list runs to hundreds of values and needs its own maintenance process, a lookup to a custom object gives you searchable selection, per-value attributes, an owner, and an activation flag, at the cost of a relationship. The switch is painful later and cheap early, so make the call when the list starts growing rather than when it becomes unmanageable.
Frequently asked
Does renaming a picklist label break my validation rules? No, if the API name is unchanged. Formulas compare the stored value. Check any rule that compares against the field with TEXT() and a literal string, because those compare differently from ISPICKVAL.
Do multi-select picklists work the same way? The label and value behaviour is the same. Everything else is harder: they filter awkwardly in reports, need INCLUDES() in formulas, and are unavailable in several places ordinary picklists work.
How do I find which fields use a global value set? The value set’s detail page lists the fields that reference it. Check it before changing anything, because the blast radius is larger than a single field.
