Dropdown (Single) (DB)
A dropdown whose options are records in another datastore. One choice, stored as a reference to that record.
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
This is a relationship
The important framing: this is not a list of words, it is a link between two records. The field stores which record was chosen, so everything about that record is reachable from this one.
That is what a manual list cannot do, and it is why this type is the right default for anything the business maintains.
It joins, so it reports well
Single-select types are joinable — the stored value points at one thing, so a report can join through it and group by the source record. That is what makes "count by category" a query rather than an exercise.
So "cases by category" or "orders by customer" is a report joining through this field, and the source record's other fields are available to it.
What it gives you
- One place to correct a name. Renaming a category updates every record referencing it, because they reference it rather than copying it.
- Options that carry data. A category can have an owner, a colour, an active flag — all reachable from the record that chose it.
- Business-maintained lists. Adding an option is adding a record, which needs no architect.
- Its own permissions and audit. The option list is a datastore like any other.
Retiring an option
Do not delete a record that has been referenced — historical records point at it and will be left pointing at nothing.
Give the source datastore an "active" flag instead, filter the dropdown to active records, and mark the obsolete one inactive. Existing references keep resolving and nobody can choose it again.
Filter what is offered
A dropdown can be restricted to a subset — active records, or ones matching something on the current record. That keeps the list short and stops people choosing something inapplicable, which is better than validating it afterwards.
When the list gets long
Past a few dozen options, use the searchable variant. A plain dropdown of six hundred customers is unusable, and users will pick something near the top rather than scroll.
Think about what happens on delete
Decide what should happen to records referencing an option if it is ever removed. "Nothing, because we never delete them" is a legitimate answer — but it should be a decision rather than something discovered.
Worked example
A ticket datastore links to a Categories datastore, each category carrying a default team and an active flag. The dropdown is filtered to active categories. When a category is retired it is marked inactive rather than deleted, so two years of historical tickets still report correctly under it.
Recommendations
- Prefer this to a manual list for anything the business maintains.
- Never delete a referenced record — use an active flag.
- Filter the dropdown to what is currently valid.
- Switch to searchable once the list is long.