Lookups
Summary
Lookup fields are editable fields bound to a related table. The user can browse and select a value (Ctrl+Enter) or type directly and have the value validated on blur.
User-facing behavior
On a field with a lookup:
| Key | Action |
|---|---|
Ctrl+Enter | Open the lookup list (see Keyboard Shortcuts for alternates) |
| Type + leave field | Value is validated against the server |
If validation fails, the user is locked on the field until they fix the value or press Esc to revert.
When opening a lookup, the client sends the current field value so the server can position the list on the matching row.
Two types of lookup
Strict lookup (validated)
The lookup list opens with a search or browse interface. On blur, the client calls the server to check the value. If invalid, the field is locked.
Helper lookup (no validation)
The field has a lookup list but the user can type any value — the lookup is just a convenience.
Autofill
When a lookup value is resolved (via selection or validation), related fields on the card can update automatically. This is called autofill.
For example, selecting postal code 100 autofills city: "Tórshavn" to the city field.
| Trigger | Autofill? |
|---|---|
| Lookup selection (Enter on row) | Yes |
| Blur validation (valid response) | Yes |
| Esc from lookup | No |
| Invalid blur validation | No |
Autofill-updated fields are marked dirty and included in the save changeset. Autofill does not trigger further validation — the values come from the server and are already valid.
Modal vs full-screen lookups
| Behavior | Best for |
|---|---|
| Full-screen list pushed onto stack | Large datasets (customers, items) |
| Centered modal with client-side filtering | Small datasets (postal codes, payment terms) |
Modal lookups load all rows at once and support client-side fuzzy filtering with no server round-trips.