A picklist is one of the most common fields in any Salesforce org. Creating one takes a minute. Managing the value set, controlling availability per record type, and keeping integrations in sync takes a quarter. Plan the value taxonomy before you create the field because each value becomes a contract with users, reports, Apex, and external systems.
- Decide between local and global value sets
If the same list of values will be used on multiple fields across objects, create a global value set first at Setup > Picklist Value Sets. If the values are specific to one field, a local value set is simpler and gives more reorder flexibility.
- Create the picklist field
Object Manager > target object > Fields and Relationships > New > Picklist (single-select) or Multi-Select Picklist. Enter the values one per line, or reference the global value set. Set a default value if applicable.
- Turn on "Restrict picklist to defined values"
For new picklists, check the Restrict checkbox. This blocks integrations and Apex from inserting unknown values, which keeps data quality high from day one. Skip this only if a known integration requires legacy permissive behavior.
- Configure record type availability
If the object has record types, go to each record type and edit the picklist availability. Specify which values appear and which is the default for that variant. Repeat for every record type that should see the new field.
- Set field-level security per profile
Profiles without read access see the field as blank or hidden. Permission sets layered on top can grant additional access. Verify the field is visible to the profiles that need to see it before going live.
- Configure dependent picklists if applicable
If this picklist depends on or controls another, set up the dependency. Setup > Object Manager > Fields and Relationships > Field Dependencies > New. Map the matrix of which dependent values appear for each controlling value.
- Document the values and the change-control process
Picklist values become contracts with reports, Apex, and integrations. Write down what each value means, who can request changes, and what review is required. Surprise value changes break downstream automations more often than admins expect.
Label appears in the UI. API name is permanent and referenced by validation rules, Apex, and reports.
The list of values users can pick. Local lives on the field; global is reusable across fields.
Controls whether the API blocks values outside the defined set. Enable for new fields to enforce data quality.
- Without "Restrict picklist to defined values" enabled, integrations can insert any string value, which silently corrupts reports and breaks list view filters. Turn it on for new picklists.
- Renaming a picklist value changes the field metadata but not the data on existing records. Plan a bulk update job alongside the value rename, or reports will show both old and new values for weeks.
- Picklist value availability per record type must be configured manually after each record type is created. New picklists added later default to showing all values until you explicitly filter per type.
- Apex code, validation rules, and integrations often hard-code picklist value strings. Audit every Apex class, validation rule, and integration mapping before deactivating or renaming a value.
- Multi-select picklist values are stored as semicolon-delimited strings, which makes reporting and Apex filtering awkward. Prefer separate boolean fields or a related junction object for values that need clean reporting.