Short answer: use a picklist whenever anyone will ever group, filter or report on the field, and use text only when the content is genuinely open. Free text is cheap to build and expensive forever after, because nobody can count it. A picklist is the opposite: a small ongoing maintenance cost in exchange for data you can trust in a report. The deciding question is not how many values there are, it is whether the field will ever appear in a chart.
What free text actually costs
A text field accepts whatever the user types, and users type everything. Within a year a two hundred record object has “London”, “london”, “London, UK”, “LDN” and “Londn” in the same column. None of that is a data quality failure you can point at, because every one of those entries is correct English.
The bill arrives in reporting. Grouping by a text field produces one row per distinct string, so a report meant to show five regions shows forty. Bucket fields paper over it, at the cost of a bucket that needs a new entry every time someone invents a spelling. Filters miss records because the operator wrote “equals” and the data says something one space away.
Automation suffers the same way. A Flow branching on Region__c = "EMEA" silently takes the wrong path for “emea”. You will not see it in a debug log because nothing failed.
What a picklist costs
Real costs, and worth being honest about them.
- Every new value is a change in Setup, which in a controlled org means a deployment, which means a lead time. Sales will ask for a new value the day before a campaign launches.
- Values referenced by formulas, validation rules and Flow are compared by API name, so renaming a label is safe and changing an API name is a breaking change with no automatic fixup.
- Lists grow. Once a picklist reaches a hundred values with its own approval process, it has become a data object wearing a picklist costume.
- An unrestricted picklist quietly accepts anything the API sends, so you get free text behaviour anyway with none of the warnings.
That last one is the important one. If you choose a picklist, mark it restricted. An unrestricted picklist is a text field that looks tidy in Setup.
The middle ground people forget
When the list is long, changes often, has attributes of its own, or needs an owner, a lookup to a custom object beats both options. You get searchable selection, an active flag, effective dates if you need them, and the ability to report on the referenced record rather than a string. The cost is a relationship and a slightly heavier UI.
The rule of thumb that has held up: under about thirty values that change once or twice a year, picklist. Over that, or maintained by someone outside the admin team, custom object.
Dependent picklists change the maths
If a field’s valid values depend on another field, text is off the table entirely. Dependent picklists require picklists on both sides, and the controlling field must be a picklist or a checkbox.
This matters more than it first appears because it is a design constraint that arrives late. Somebody builds Product Family as text, then six months later wants Product to be filtered by it, and now the fix is a field type change on populated data plus a migration. Deciding early is nearly free. Deciding late is a project.
Converting text to picklist
The field type change wizard will let you. What it will not do is clean your data. The conversion keeps existing strings, so records carrying “london” hold a value that is not in the list, and you cannot make the field restricted until they are gone.
The order that works: report on the field grouped by value to see the full distribution, decide the target list, mass update the strays with the data loader, then convert, then restrict. Doing it in any other order leaves you converting twice.
Frequently asked
Is a picklist faster to filter than text? Slightly, because the comparison is against a small set of stored values rather than arbitrary strings. On ordinary volumes you will not notice, so choose on reporting quality instead.
What about multi-select picklists? Avoid unless the requirement is genuinely many values per record. They filter badly in reports, need INCLUDES() in formulas, cannot be a controlling field, and are unavailable in several places ordinary picklists work.
Can I make a text field behave like a picklist with a validation rule? You can, and it is the worst of both. Users get no list to pick from, they get an error after typing, and the allowed values live in a formula nobody thinks to look at.
