Creating a multi-select picklist is mechanically identical to creating any other custom field, but the design conversation should happen first. Most teams that reach for a multi-select picklist end up wishing they had built a junction object instead, because the reporting limitations surface six months in. Build a one-page decision document before the field, and revisit it whenever someone asks for "another tag.""
- Confirm the tradeoff fits the use case
Ask: will anyone need to report on this field grouped by individual value? Will Apex or Flow need to filter on combinations of values? Will the value list grow significantly over time? Three yes answers point at a junction object. If all three are no, a multi-select picklist is the right tool.
- Create the field
Object Manager > target object > Fields and Relationships > New > Multi-Select Picklist. Enter the values one per line. Specify the visible lines (number of values shown in the UI before scrolling). The default is four, which works for most use cases.
- Choose between local and global value set
If the same value set will be used on multiple multi-select fields across objects, reference a global value set instead of typing values locally. Global value sets keep multi-select picklists in sync across the org, just like single-select.
- Configure record type availability
For each record type on the object, edit which multi-select values are available and which are the default selections. Default selections pre-populate but users can change them on save. Plan defaults conservatively because users tend to leave whatever is pre-selected.
- Add the field to page layouts and set FLS
Place the field on the relevant page layouts. Field-level security per profile determines who can see and edit. Multi-select picklists render larger than single-select on the UI, so position them in a section where the visual weight makes sense.
- Update validation rules with INCLUDES syntax
Any validation rule that needs to react to specific selected values uses INCLUDES(field, "value"). Combine with AND/OR for compound checks. Test thoroughly because compile-size limits hit faster than with single-select equality.
- Document the value list and review cadence
Multi-select value lists grow over time as new tags get requested. Document the values, their meanings, and a quarterly review process to deprecate unused values. Without this discipline, multi-select fields become unmanageable in 18 months.
Label appears in the UI. API name is permanent and referenced by validation rules, Apex, and integrations.
The list of values users can pick from. Global value sets reuse across fields; local stays per field.
Number of values shown in the UI before scrolling. Default is four. Affects how the field renders on page layouts.
- Reports cannot group cleanly across multi-select values. A report grouped by the field shows one row per unique combination of selections, not one row per value. Plan for junction objects if grouped reporting matters.
- Apex must parse the semicolon-delimited string to check membership. Use the INCLUDES function in SOQL and validation rules. Compile-size limits on validation rules hit faster than with single-select equality checks.
- Multi-select picklists do not work well with global picklist value restrictions on every operation. Migrations and integrations need careful handling because the field is stored as text under the hood.
- Adding new values is cheap, removing them is expensive. Existing records still hold the old value, and reports surface deactivated values until a cleanup job runs through every affected record.
- The 500-values-per-selection limit and the field's character limit cap real-world growth. Long selections truncate silently and produce confusing user experiences. Audit selection patterns periodically.