AJAX Search (DB)
A type-ahead search that looks up records in another datastore as the user types.
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 being searched
How it differs from a searchable dropdown
Both search another datastore and both store a link, and both are joinable — so the difference is in the interaction rather than the data.
A searchable dropdown presents a list you filter. This presents a search box that suggests as you type. For very large sets, or where the user is starting from something they know rather than choosing from options, the search feels more natural.
In practice either works for most cases. Pick one and use it consistently, because a form mixing the two for no visible reason looks arbitrary.
Search what the user knows
The same rule as any lookup, and it is the thing most often got wrong. Somebody looking for a company knows its name; searching only on a reference code fails them.
Cover the identifiers people actually hold, and prefer matching within a value rather than only from the start — users type the distinctive word, not the first one.
Show enough to choose correctly
Three results reading "J Smith" are not choosable. Include something that separates them — a town, a date of birth, an account number — so the user picks right first time rather than opening each in turn.
Handle the empty result
Somebody will search for something that is not there. Say so clearly, and give them a route — create it, or a note explaining why they cannot.
Without that, people put the value into a nearby free-text field and continue, which produces exactly the unlinked, duplicated data the field existed to prevent.
Filter to what is valid
Restrict to active records, or to records that make sense for the context. A search returning long-closed accounts will have one chosen eventually, and validation afterwards is a worse experience than not offering it.
Mind the responsiveness
The field searches as somebody types, so it runs frequently against a datastore that may be large. If results feel slow, the fix is usually indexing or narrowing what is searched rather than anything on the form.
It is still a relationship
Everything about database-backed dropdowns applies: do not delete a referenced record, use an active flag to retire options, and remember the source datastore has its own permissions — a user who cannot see a record will not find it here either, which is correct and occasionally confusing.
Worked example
A booking form uses AJAX search to find the customer, matching on name, account number and telephone, showing the town and account number in the results, filtered to active accounts. A "not found — create customer" option sits under the results, so nobody types a name into the notes instead.
Recommendations
- Search on everything the user might know.
- Show a distinguishing detail in results.
- Give a route for "not found".
- Be consistent — do not mix this and searchable dropdowns arbitrarily.