Dropdown (Searchable) (DB)
A database-backed dropdown that lets the user type to filter. Same stored value and same relationship as the plain variant; a different control.
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 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.
Use it for anything long
The threshold is lower than people expect — a few dozen options is enough. Scrolling a long list is slow, and worse, it changes behaviour: users pick something visible near the top rather than the right answer further down.
Typing three characters to narrow six hundred customers to two is faster and more accurate than any amount of scrolling.
Search what people actually know
Make sure the searchable text is what the user has in their head. Somebody looking for a customer knows the company name; they may not know the account code. A field searching only on a code fails the person holding a name.
Where several things identify a record, let the search cover them.
Show enough to disambiguate
"Smith" is not a useful result three times over. Include something that distinguishes them — a town, a reference, a date of birth — so the user can pick correctly without opening each one.
This is the commonest complaint about searchable dropdowns and it is a configuration matter, not a limitation.
It still needs filtering
Searchable does not mean unfiltered. Restrict to active records as you would a plain dropdown — a searchable list of every customer who ever existed will surface closed accounts, and somebody will choose one.
Think about the empty state
What a user sees before typing matters. Showing nothing is honest but leaves people unsure whether the field works; showing a first page gives them something to react to. Either is defensible — decide rather than leaving it to chance.
What if it is not there?
Somebody will search for a record that does not exist yet. Make sure there is an obvious next step, because the alternative is a user typing the name into a notes field and moving on — which is how duplicate and unlinked data appears.
Prefer it as the default
For database-backed dropdowns, searchable is a good default even for medium lists. It behaves like a plain dropdown when the list is short and stays usable when the list grows — which it will.
Worked example
An order form links to Customers through a searchable dropdown filtered to active accounts, searching on company name, trading name and account code, and showing the town beside each result. Sales staff find a customer in two or three keystrokes, and the three "Smith Ltd" entries are distinguishable at a glance.
Recommendations
- Default to searchable for database-backed dropdowns.
- Search on what the user knows, not only on a code.
- Show a distinguishing detail in the results.
- Give people a route when the record does not exist.