Enumeration Field
An Enumeration Field in Salesforce is a field whose value must come from a predefined list of options rather than free text.
Definition
An Enumeration Field in Salesforce is a field whose value must come from a predefined list of options rather than free text. The platform expresses this idea in two places. On the database side, the Picklist field type holds one approved value per record, and the Multi-Select Picklist holds several. In Apex code, the enum keyword declares the same concept as a strongly typed list of named constants.
Enumeration fields keep data consistent. Without them, a single concept arrives in many spellings (Tech, Technology, Tech and Software, IT, Information Technology), and every report, filter, and integration has to account for the variation. A picklist forces one of a known set, so reports group cleanly and automation can compare against fixed values. The platform stores picklist values as text but enforces the allowed set when a record is saved.
How enumeration shows up across the platform
The Picklist as the standard enumeration field
A Picklist is the most common enumeration field, and most admins reach for it daily. You create it under Setup, Object Manager, the object, then Fields and Relationships, then New, then Picklist. You type the values and arrange their order, which also controls how they appear in the dropdown unless you choose alphabetical sorting. The field stores text under the hood, but the platform only accepts a value that belongs to the configured list when a save passes through the standard UI. Picklists are first class almost everywhere. They render as dropdowns on page layouts, they group and filter in reports, and SOQL references them as ordinary string fields. A picklist value also carries an API name separate from its label, which matters for translation and for keeping integrations stable when someone renames the label. Each picklist value can be marked active or inactive, so you retire an option without deleting historical data that already uses it. That separation of label, API name, and active state is what makes a picklist safe to evolve over years.
Multi-Select Picklists and their reporting cost
A Multi-Select Picklist lets one record hold several values from the same list. The platform stores the selection as a single semicolon-delimited string, so a record might carry Industry equal to Tech;Healthcare;Finance in one field. Users like the convenience of ticking several boxes at once, which is why these fields spread quickly in young orgs. The cost shows up later, mostly in reporting and queries. A report cannot easily count records by an individual value, because the stored value is the whole combined string. Filtering needs the INCLUDES operator instead of a plain equals, and sorting works on the raw string rather than on any single choice. Integrations also have to split and rejoin the delimiter, which is a common source of mapping bugs. Salesforce caps how many values an org can select at once, and large multi-select fields hit that ceiling. When a question really needs many-to-many data, a child object with one record per value usually serves better than a multi-select field.
Restricted Picklists and why they matter
Restriction decides how strict the enumeration actually is. A plain picklist enforces its list through the user interface, but historically it could still accept an off-list value when a record was written through the API or Apex. The platform recorded that value even though no admin had defined it, which let bad data slip in behind the form. A Restricted Picklist closes that gap. It is a checkbox on the field definition, and once it is on, any value outside the list is rejected on every path, including the API. When code or an integration sends an unknown value, the save fails with the error bad value for restricted picklist field, which is a signal you want, not one to suppress. Marking a field restricted is the difference between a list that suggests options and a list that enforces them. Most production fields should be restricted from the day they are created, because retrofitting restriction onto a field that already holds messy data means cleaning the data first.
Global Picklist Value Sets
A Global Picklist Value Set defines a list of values once and shares it across many picklist fields. You build the set in Setup under Picklist Value Sets, then base individual picklist fields on it instead of typing values into each field by hand. Industry, Country, or Region defined this way stays identical on Account, Lead, Contact, and any custom object that points at the same set. Editing the set updates every field that inherits from it, which removes the drift you get when the same list is maintained in thirty separate places. A global value set is restricted by nature. Only an admin can change its values, and users cannot add unapproved ones, even through the API. Each set supports up to a combined 1,000 active and inactive values, and an org can hold up to 500 of these sets. One sharp edge is permanence. You cannot undo a field's association with a global value set, so moving a field to a different set means deleting that field and creating a new one. Plan the source of values before you wire fields to it.
Dependent Picklists
A Dependent Picklist narrows its available options based on the value chosen in another picklist on the same object. The field that drives the behavior is the controlling field, and the field that reacts is the dependent one. You connect them under Fields and Relationships, then Field Dependencies, where a grid lets you tick which dependent values are valid for each controlling value. A worked example makes it concrete. Suppose Lead Source is the controlling field. When a user picks Inbound, the dependent Lead Subtype offers only Web Form, Email, and Phone. When they pick Outbound, the same subtype field offers Cold Call, LinkedIn, and Trade Show. The user never sees a combination that does not make sense, so the data stays internally consistent without a single line of code. Dependencies push business logic into metadata, which keeps validation rules shorter and reduces free-text drift. A controlling field can be a standard or custom picklist, and a checkbox can act as a controlling field too, with its two states driving the dependent options.
The Apex enum and its methods
In Apex, enum is the code-level form of an enumeration field. You declare it as a type, for example public enum CaseStatus { New, InProgress, OnHold, Closed }, and any variable of that type can only hold one of those named constants. The compiler rejects anything else, so a typo that would survive in a string becomes a build error instead of a runtime surprise. That compile-time safety is the main reason to prefer an enum over loose string constants in logic. Apex enums come with built-in methods. values returns every constant in the enumeration, name gives the constant's text, ordinal returns its zero-based position, and valueOf converts a matching string back into the enum constant. The platform also ships its own enums, such as LoggingLevel and System.StatusCode, that you use directly. A common pattern bridges code and configuration: a small method maps each picklist text value to an enum constant and throws a clear error for anything unrecognized. That keeps the database list and the code list in step, so adding a picklist value forces a deliberate update to the matching enum.
Reporting, filtering, and integration behavior
Choosing between a single Picklist and a Multi-Select Picklist is often a reporting decision more than a user-experience one. A single-select picklist supports exact filters, grouping, and per-value record counts with no special handling, so dashboards built on it stay simple. A multi-select field needs the INCLUDES operator to match a value, and counting by individual choice usually requires reshaping the data into one row per value. If a metric depends on counting each option separately, the single-select design wins almost every time. Integration behavior also depends on enumeration choices. Picklists travel as plain strings over the API, which keeps mappings straightforward, but the receiving system must respect the same allowed set or a restricted picklist will reject the write. API names give you a stable contract even when labels change for end users, so external systems can keep sending Tech_Software while the screen reads Technology and Software. Treat the picklist API name as part of your integration agreement, and avoid renaming it once another system depends on it.
Create a Global Picklist Value Set
Create a Global Picklist Value Set so several fields share one governed list of enumeration values. Build the set once, then base each picklist field on it. Editing the set later updates every field that points at it.
- Open Picklist Value Sets in Setup
In Setup, use Quick Find to open Picklist Value Sets. This is where global sets live, separate from any one object. Click New next to Global Value Sets to start a fresh list.
- Name the set and enter values
Give the set a clear label and API name, then type each value on its own line in the order you want them shown. The set is restricted by nature, so only admins can change these values later.
- Create a picklist field based on the set
On the target object, add a new Picklist field. When asked for values, choose the option to use a global value set and select the one you created. Repeat on every object that needs the same list.
- Verify the shared behavior
Edit one value in the set and confirm the change appears on every field that inherits it. Reports and filters now reference one consistent list across the org.
The human-readable name of the value set shown to admins. Pick something that names the concept, like Industry or Country.
The list of allowed entries, one per line, with an active or inactive state each. Combined active and inactive values cap at 1,000 per set.
The choice, when building a picklist field, to base it on this global set instead of local values. This association cannot be undone later.
- You cannot reverse a field's association with a global value set. Switching sets means deleting and recreating the field.
- A global value set is always restricted, so off-list values are rejected on every path, including the API.
- An org allows up to 500 global value sets, and each set holds at most 1,000 active and inactive values combined.
Trust & references
Cross-checked against the following references.
- Enums | Apex Developer GuideSalesforce
- Create a Global Picklist Value Set | Salesforce HelpSalesforce
Straight from the source - Salesforce's reference material on Enumeration Field.
Hands-on resources to go deeper on Enumeration Field.
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 is an Apex enum?
Q2. How do enums differ from picklists?
Q3. What's a benefit of using enums over strings?
Discussion
Loading discussion…