← All posts
Productivity Tips6 min read

Select, Multi-Select, Status or Checkbox: Choosing a Choice Field

Which choice-shaped field to use and what breaks if you pick wrong — why Status is special, the one-vs-many test, and when a checkbox is a mistake.

Select, Multi-Select, Status or Checkbox: Choosing a Choice Field

Four field types in the picker look like they do the same job: they all constrain a value to a set of options. They are not interchangeable, and the difference only becomes visible later — when you try to build a board and find you cannot group by the column you have been filling in for six months.

The short version: Status represents where something is in its life, and the rest of the system treats it specially. Everything else here is an ordinary field.

If the vocabulary is new, the building blocks of your workspace covers how fields sit in the model.

What are the choice-shaped field types?

Five, once you include the two people forget:

  • Select — one value from a fixed list. Region, source, tier.
  • Multi-Select — several values from a fixed list. Tags, affected areas.
  • Status — one value from a fixed list, representing a stage in a lifecycle. To do, in progress, done.
  • Checkbox — true or false. Approved, archived, billable.
  • Pipeline — a stage within a defined pipeline, for work that moves through a commercial process.

All five constrain input, which is their shared virtue: they make a column groupable forever, where free text does not. That argument is made in full in how to structure a sheet, and it holds for every type on this list.

When do you want Status rather than Select?

When the value describes where the item is in a process, rather than what kind of thing it is.

That sounds like a philosophical distinction and it is an entirely practical one. A Status field is what a board groups its columns by, and it is the field a workflow watches when you want something to happen as work progresses. Model your lifecycle as a Select and you get neither: no board columns to drag between, and a much clumsier automation.

The test is whether values replace each other over time in a predictable direction. To do becomes In progress becomes Done — that is a lifecycle, so Status. Enterprise does not become Mid-market in the normal course of events — that is a category, so Select.

A useful second test: if you were drawing this on a whiteboard, would it be columns with arrows between them? Status. A legend? Select.

This is also the field type an AI agent's work policy names when it picks a task up and hands it back — another thing you forfeit by modelling a lifecycle as a Select.

Select or Multi-Select — the one-vs-many test

Ask whether a single row could legitimately need two answers at once. If yes, Multi-Select. If no, Select.

Most people get this right by instinct, but two consequences are worth knowing before you choose.

First, Multi-Select cannot be sorted. Grouping and filtering work fine, but there is no meaningful order for a cell holding three values, so a Multi-Select column will not give you a sort. If you need to order rows by this value, you need a single-value field.

Second, Multi-Select quietly invites sprawl. Because a row can hold many, nothing forces the discipline of choosing, and the option list grows until it is a tag cloud that means nothing. If your Multi-Select has thirty options and the average row uses six, it has stopped being a categorisation and become free text with extra steps.

When genuinely unsure, start with Select. Widening later is a conversation; narrowing a Multi-Select means deciding which value on each row was the real one.

Is a checkbox ever the right answer?

Yes, but less often than it gets used, and there is a specific trap.

A checkbox is right when the fact is genuinely binary and permanently so: billable or not, archived or not. It is groupable and sortable, so it behaves well in views.

The trap is that a checkbox cannot distinguish false from unanswered. An unticked box means either "no" or "nobody has looked at this yet", and there is no way to tell which. For anything where that difference matters — approvals especially — use a Select with explicit options (Pending, Approved, Rejected) so the empty state is visible rather than silently reading as a no.

The other common mistake is a row of checkboxes that are really one choice. Three boxes named Small, Medium and Large is a Select wearing a disguise, and it permits nonsense states where two are ticked.

What is Pipeline for?

Pipeline is for work moving through a defined commercial process — a sales pipeline being the obvious case — where the stages belong to the pipeline itself rather than being an ad-hoc list on one sheet.

It groups and sorts like the others, so it behaves normally in views. The reason to reach for it over a plain Status is when the stages are a property of a process your organisation has defined, rather than a set of columns one team invented for one board.

If you are not sure whether you have a pipeline or just a lifecycle, you have a lifecycle. Use Status.

How many options is too many?

About a dozen, for any of these types, and the symptom of exceeding it is always the same: the options stop being categories and become individual cases.

When a Select has forty options, several things go wrong at once. The board grows forty columns and stops being readable at a glance. Every option holds one or two rows, so grouping tells you nothing. And people pick inconsistently, because nobody can hold forty options in their head, so the data stops being comparable.

Three fixes, in order of preference:

  1. Merge. Most long option lists have obvious families. Collapse to the families and you usually lose nothing anyone was using.
  2. Split into two fields. A long list is often two questions wearing one hat — stage and reason, or type and source. Two short fields beat one long one, and they can be grouped independently.
  3. Make it a relation. If the options are real things with attributes of their own — clients, products, campaigns — they belong in their own sheet, linked by a relation rather than duplicated as options.

That third one is the upgrade path people miss. An option list is for values that are just labels. The moment you want to know something about an option, it has become a thing, and things live in sheets.

Choosing, in one pass

Run the questions in this order and you will land correctly almost every time:

  1. Does the value describe a stage the item moves through? → Status (or Pipeline for a defined commercial process).
  2. Can one row need several at once? → Multi-Select.
  3. Is it genuinely yes-or-no, and does unanswered-versus-no not matter? → Checkbox.
  4. Otherwise → Select.

And if the option list is heading past a dozen entries, stop and ask whether you are looking at a relation instead.

Start free and check whether the field your board depends on is actually a Status.

DK
Daniel Kroes

Put AI to work in your own workspace

Start free and see what your team can do with a real thinking partner.

Start free