Pick a record.
Get a record.
lookup queries a list asset — a CSV, JSON list,
or REST endpoint — and returns a structured record with any
number of named fields. Five variants cover ZIP screenouts,
state → region pipes, employee directories, make → model
cascades, and silent target-list validation.
- 10001 Manhattan NYNortheast · New York
- 10013 Tribeca NYNortheast · New York
- 10021 UES NYNortheast · New York
Server-side search as the respondent types. For large assets — ZIP, device, SKU.
- Northeast
- New YorkNY
- MassachusettsMA
- South
- TexasTX
Browseable list with optional category headers via source.groupBy.
- 3 Series
- 5 Series
- X3
Each step filters to the prior step's resolved value. Make → Model, Country → Region → City.
Plain text input; server checks the list on Next. Keeps the target list private.
- F41 Generalized AnxietyPsychiatry
- E11 Type 2 DiabetesEndocrinology
Chip-based multi-record selection with min / max enforced.
Where lookups actually show up
In practice, lookups cover the parts of a questionnaire that
can't live inside the survey file — the lists are either
proprietary and client-supplied (targeting
ZIPs for a geographically-scoped study, approved NPIs for a
physician panel, qualifying employee IDs for a B2B wave,
valid product serial numbers for an owner-only recruit) or
they're simply too large and too structured
to hand-code into a single question — ICD-10
codes, medical device catalogues, vehicle makes and models,
global SKU lists, geographic hierarchies.
Upload the list. Reference it in one line.
The alternative — pasting every make, every model, every ICD-10 code into the YAML as a static option list, then wiring the dependencies between them by hand — is the classic survey-programming time-sink. It's slow, it's error-prone, and the list goes stale the moment the client adds a new SKU. With a lookup, the authoring team uploads the CSV (or points at the client's REST endpoint) and references it in one line:
source: lists.fieldbase.com/lookup/vehicle_makes_modelsThree hundred makes and five thousand models become one cascading question. When the client sends an updated list, you replace the asset — the survey doesn't need to be re-coded.
The list stays on the server
Every variant resolves server-side. The
respondent's browser never downloads the asset — a
proprietary ZIP target list, a confidential employee
directory, or a client's wholesale SKU catalogue is
never exposed in a view-source, a dev-tools
network tab, or an export of the page. For corporate and
regulated research teams working under NDA with their
clients' data, that's not a nice-to-have — it's the only
way the list is allowed anywhere near the fieldwork
platform. The matchOnly variant goes a step
further: the respondent doesn't even see whether
there's a list, so a targeted ZIP study can't be
reverse-engineered into a fraud vector.