Fields
A field is one piece of a record — a movie’s plot, a product’s price, a shop’s location. Every record in a list has the same fields, and each field has a type. The type is the important part: it decides what search is allowed to do with that value. The same word stored as one type is matched by a query; stored as another it is filtered on; stored as a third it is just handed back to your page untouched.
There are four types, and a list mixes as many as it needs. Pick a field’s type by asking what you want to do with it:
| You want to… | Use a | Example |
|---|---|---|
| Find records by typing words | Searchable field | title, plot, bio |
| Filter, count or sort by an exact value | Facet field | year, brand, price |
| Search by distance from a point | Coordinates field | a shop’s location |
| Return a value your page draws but never searches | Resource field | image_url, a deep link |
Auto-plays · use Back / Next to step through at your own pace.
Add a field
Open a list and use the Fields menu — there is one entry per type. Add as many as you like; existing records are re-indexed automatically when a field is added.
Searchable fields — the ones a query matches
A searchable field is part of the full-text index. Its content is tokenised, normalised and scored, so a single query matches across every searchable field at once, with relevance ranking, prefix matching and typo tolerance.
- Relevance ranked — closer matches, and matches in more important fields, score higher.
- Prefix matching —
incepmatches Inception, which is what makes type-ahead suggestions work as the user types. - Typo tolerance — a small misspelling (
kenau→ Keanu) still matches. - Cross-field — you don’t pick a field per query; the query is checked against all searchable fields together.
Every list starts with a searchable name field. Good extra ones are title, description, plot, bio, synopsis — anything a person would type words from.
Facet fields — the ones you filter and count
A facet is a structured, exact-match value: category, brand, year, price, in_stock. Facets are not part of the full-text index and play no part in relevance. Instead they do two jobs: they power the filter on a search, and they can be counted to build a guided-navigation sidebar — the “Brand: Sony (12), Brand: Apple (8)” list you see on most shopping sites.
When you add a facet you choose its type — String, Number, Date or Boolean. The type is what makes typed comparisons work: year gt 2000 compares numbers, in_stock eq true compares booleans. It can’t be changed once values are saved, so pick it up front.
Filtering on facets
The filter is a small expression that narrows a search to records whose facet values match — exact, evaluated on the server, and combined freely with the typed query. So “search for matrix, but only rows where year gt 2000” is a single request. The grammar is a subset of OData filter expressions, the same syntax you may know from Azure AI Search:
| Operator | Means | Example |
|---|---|---|
eq / ne | equal / not equal | city eq 'London' |
gt / ge | greater than / or equal | price ge 100 |
lt / le | less than / or equal | age lt 90 |
and / or / not | combine conditions | year ge 1990 and year lt 2000 |
String values go in single quotes ('London'); numbers and booleans are bare. A few worked examples:
| Goal | Filter expression |
|---|---|
| Records from 2013 | year eq 2013 |
| Records from the 1990s | year ge 1990 and year lt 2000 |
| London or Paris shops | city eq 'London' or city eq 'Paris' |
| In stock, not on clearance | in_stock eq true and not (status eq 'clearance') |
Only facet fields can appear in a filter — searchable and resource fields cannot. When building requests by hand, URL-encode the expression (spaces become %20).
Coordinates fields — search by distance
A coordinates field stores a latitude,longitude pair on each record and switches on radius search for the list. There is nothing to name — one click adds it. The field itself is never searched or filtered directly; it is read by the radius option on a search, which restricts results to those within a set distance of a point (in miles or kilometres, per the list’s settings). Each result also comes back stamped with a computed distance, so your page can show “23 miles away” with no extra maths.
Radius combines with everything else: “coffee shops matching espresso, within 2 km, rated 4+” is one request. Try it on real data in the Geographical Search tutorial.
Resource fields — carried, not matched as text
A resource field carries payload data alongside a record but is left out of both the text index and the filter engine — the value itself (a URL, a slug, an ID) is never matched against what a visitor types. Use it for values your front-end needs to render a result — image URLs, deep links, thumbnails, external IDs:
<img src="${data.image_url}" alt="${data.name}" />One useful twist: when the list’s embedding model can read files, the file a resource points at does join the search, even though the value never word-matches. A resource holding picture URLs powers image search and look-alike matching, and one pointing at PDFs makes their contents findable — see Searching for how document matches are scored.
A worked example
Picture a list of movies. You make plot and name searchable, so “dream heist” finds Inception. You add year as a Number facet, so the same search can be narrowed with year gt 2000 and a sidebar can show how many titles each decade holds. You add image_url as a resource, so every result carries its poster without ever being searched on. One list, three field types, each doing exactly one job — that is the whole skill of designing a list: give every value the type that matches what search should do with it.