AJAX Search (URL)
A type-ahead search that queries an external service rather than a local datastore.
Where to find it
Architect Panel → Data:
- Datastores — the datastore, then Table Designer to add or edit a field
Architect Panel → Integration & Connections:
- API Clients — outbound connections generally
- Data Sources — the alternative, for data you want held locally
What it stores
What the service returned, as text. Unlike the database-backed search, this does not join — there is no local record to join to, only a value that came from elsewhere.
That is the fundamental difference and it decides most of what follows.
When it fits
- Reference data maintained by somebody authoritative — a registry, a directory, a standards list.
- Lookups you have no wish to hold or maintain copies of.
- Values that change at the source and should always be current.
What you inherit
A dependency on somebody else's availability and speed, on every keystroke. If the service is slow, your form is slow; if it is down, your form cannot complete.
That is a real operational consideration for a field people use daily, and it is worth deciding deliberately rather than discovering.
Fail visibly, not silently
The most important design point. When the service does not respond, the user must be told — "we cannot reach the lookup service" is actionable; an empty result list is not, because it looks identical to "no matches".
The second reading makes people conclude their search term is wrong and try again, repeatedly.
Allow a manual fallback
Where the field is on a form that must be completable, provide a way through when the lookup fails. A form that cannot be submitted because a third party is having a bad afternoon is your outage, not theirs, as far as your users are concerned.
Reporting is limited
Because the value does not join, you cannot group or report through it as you would a local link. If the value is central to your reporting, a data source that brings the records in locally is the better shape — and that is the main reason to prefer one over the other.
Watch what you send
The user's keystrokes go to the external service. If people search by name, you are sending names to a third party on every character.
Know what that service does with what it receives, and be careful with searches over anything sensitive — this is the kind of outbound flow that is easy to overlook when reviewing what leaves your systems.
Values can go stale
What you stored was current when it was chosen. If the source later changes or withdraws it, your record still holds the old value with nothing to tell you. That is acceptable for many uses and worth knowing for the rest.
Worked example
A registration form looks up company details from an external registry, storing the returned name and number. When the registry is unavailable the field says so and manual entry is offered, so registrations continue. Company records used for reporting are brought in through a data source instead, because those need joining.
Recommendations
- Say when the lookup failed — never show an empty list.
- Provide a manual fallback on any form that must complete.
- Use a data source where you need to report on the value.
- Know what you are sending on every keystroke.