Dropdown (Multiple, Linked) (DB)
A database-backed dropdown allowing several selections rather than one.
Where to find it
Architect Panel → Data:
- Datastores — the datastore, then Table Designer to add or edit a field
Architect Panel → Data:
- Datastores — the datastore the options come from
It does not join
Multi-select fields store their selections as text rather than as a single reference, so they are not joinable. A report cannot join through this field and group by it the way it can with a single-select one.
That is not a defect — one value cannot point at three records — but it is the trade you are making. If "how many records are in each category" is a question you will ask often, a single-select field, or a proper linked datastore, will serve you far better.
When it is the right answer
- Tags and labels, where the set is descriptive rather than structural.
- A short list of attributes — languages spoken, accessibility requirements, areas of interest.
- Anywhere the selections need no information of their own.
When a linking datastore is better
The moment the relationship needs to carry anything. If you find yourself wanting to record when something was selected, who selected it, or any qualifier on the pairing, a multi-select field cannot hold it.
A person's skills is the classic example. "Which skills" fits a multi-select; "which skills, at what level, assessed when, by whom" does not — that is a datastore of its own, with a record per person-skill pairing.
Ask the question early, because converting a populated multi-select into a linking datastore is a migration.
Reporting is the real cost
Because the field does not join, questions like "how many records carry each tag" are meaningfully harder than the same question against a single-select field. If that question is central to why the field exists, reconsider the shape.
Keep the option list disciplined
Multi-selects encourage sprawl — it costs nothing to add another option and nothing to select five. Left alone, tag lists grow to hundreds of near-synonyms, and at that point they describe nothing.
Review the list periodically and merge duplicates. A tag used twice is noise.
Order the options
Long unordered multi-selects are genuinely hard to use, because the user is scanning for several things rather than one. Group or order them meaningfully, and filter to active records as with any database-backed field.
Removing an option
The same rule as single-select: do not delete a record that has been selected. Mark it inactive so existing selections still resolve.
Worked example
A volunteer datastore uses a multi-select for languages spoken — descriptive, no qualifiers needed, and nobody reports on it heavily. Availability is modelled as a separate datastore instead, one record per volunteer per session, because each needs a confirmed flag and a note. The distinction was made at design time and saved a migration.
Recommendations
- Ask whether the pairing needs attributes before choosing this.
- Use a linking datastore when it does.
- Review tag lists and merge near-duplicates.
- Deactivate, never delete, a selected option.