> For the complete documentation index, see [llms.txt](https://guides.noloco.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guides.noloco.io/views/filter-fields.md). # In-app filters In-app filters let your users narrow down the records on a view. They sit in the **action bar** above the view and open into a menu of fields the user can filter by. {% embed url="" %} {% hint style="info" %} In-app filters apply on top of any [view filters](/views/filters.md) the admin has already configured. They never expose records that the user couldn't otherwise see — [record-level permissions](/users-and-permissions/user-roles-and-permissions.md) are still enforced. {% endhint %} ## Overview Two pieces make up the in-app filter UI: * The **Filter button** in the action bar — opens a menu listing every field the user is allowed to filter by. * The **Filter bar** under the action bar — shows the active filters as **badges**, plus a **Clear all** button.
A coloured dot appears on the Filter button whenever at least one filter is active, and the action bar's record count updates to reflect the filtered total (for example, "Showing 25 of 87 **results**"). ### Filter button and menu Clicking **Filter** opens a search-first menu: * The search input is focused on open, so users can type to find a field. * Arrow keys move between options, **Enter** selects, **Esc** closes. * Selecting a field adds it to the filter bar as an active badge and immediately opens its value input.
The menu only lists fields you've toggled on in the [builder sidebar](#configuring-filters-in-the-builder). It always respects the user's field-level permissions. ### Filter bar and badges The filter bar appears below the action bar whenever there are active filters (or whenever a quick filter is set to always show — see [Filter menu vs Quick filter](#filter-menu-vs-quick-filter)). Each **active filter badge** is composed of: * **Field name and icon** — what's being filtered. * **Value** — opens a popover where the user picks one or more values. * **Action** — the operator (e.g. *contains*, *is*, *is between*). This is available when you click the filter * **X** — removes the filter. If it's the only badge in the bar (and no quick filters are configured), the bar disappears.
When the user adds many filters, the bar wraps onto multiple lines up to roughly three-and-a-half rows tall, then scrolls. **Clear all** removes every active filter in one go. Quick filters return to their inactive state but stay visible. ## Field-specific operators Each field type has its own **default operator** and its own set of available operators. The default is what the user gets the first time they add that filter; they can change it from the badge's Action menu. | Field type | Default operator | Other operators available | | ------------------------- | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | **Text** | contains | does not contain · is · is not · starts with · ends with · is empty · is not empty | | **Number** | is between | = · ≠ · > · ≥ · ≤ · is empty · is not empty | | **Single / multi-select** | is *(switches to is any of when more than one option is chosen)* | is not · is empty · is not empty | | **Related record** | is *(switches to is any of when more than one record is chosen)* | is not · is empty · is not empty | | **Rating** | is between | is · is not · is empty · is not empty | | **Boolean** | is | *(no other operators — value is Yes, No, or unset)* | | **Date** | is between | is · is not · is not between · is empty · is not empty | A few field-specific behaviours worth knowing: * **Single and multi-select** filters show a coloured dot for every selected option (up to 10), so the badge value hints at what's chosen at a glance. * **Related-record** filters work the same way as select filters, but without the colour dots. * **Date** filters include a **Select a preset** button (Today, Yesterday, Last 7 days, etc.). Picking a single-day preset switches the operator to *is* automatically; picking a range preset keeps the operator at *is between*. * **Date range** fields (start/end pair) get a sub-trigger in the filter menu so the user can choose whether to filter the **start date** or the **end date**.
{% hint style="info" %} All in-app filters combine using **AND** logic — every active filter must be satisfied for a record to appear. Within a single multi-value filter (e.g. Status *is any of* Active, Pending), the values combine with OR. AND/OR groups across filters are configured by the admin on the view filter, not in-app. {% endhint %} ## Configuring filters in the builder You configure which fields users can filter by from the **Search and in-app filters** section of the builder sidebar (Options tab).
### Default list Out of the box, every field that's currently visible on the view is added to the filter list and toggled on. That means as soon as you enable in-app filters, your users see the Filter button with all the same fields they see in the view itself — no extra setup required. ### Adding more fields Click **Add field** to bring more fields into the filter list: * A menu opens with the full list of fields and a search input focused by default. * **Click a checkbox** to add a field without closing the menu (useful for adding several in a row). * **Click the label** to add a single field and close the menu. Already-selected fields are pre-checked and can be unchecked to remove them from the list. ### Reordering and editing Selected fields appear in a single list (no separate "on" and "off" sections). On hover you get: * A **drag handle** to reorder fields — the order here controls the order in the user-facing Filter menu. * An **edit** button to open the field's filter options panel (see [Filter type per field](#filter-menu-vs-quick-filter)). * A **toggle** to disable the field — disabled fields stay in the list but no longer appear in the user-facing menu. If every field is disabled, the Filter button and filter bar both disappear. ### Action menu The section's action menu (⋯) gives you: * **Ordering** — leave at **Manual** to use your drag-and-drop order, or pick **Alphabetical A–Z** / **Z–A** to sort the user-facing menu automatically. * **Activate all** / **Deactivate all** — bulk toggle every field in the list. ## Filter menu vs Quick filter For each filter field you can choose how it appears to the user: * **Filter menu** *(default)* — the field only appears inside the Filter menu dropdown. The badge only shows up in the filter bar once the user adds it. * **Quick filter** — the field's badge is always visible in the filter bar, even when no value is set. Users can click an empty quick filter badge to set its value without going via the menu.
You change the filter type from the field's **edit** button in the builder sidebar. The field filter overlay panel gives you: * **Filter type** — Filter menu or Quick filter. * **Default operator** — preselected per field type, but you can override it (e.g. set *starts with* as the default for a Name field). * **Default value**, and **Default min / Default max** when the operator is *is between* — only shown for **Quick filters**, so users land on the view with the badge already populated. * **Show icon**, **Label**, **Help text** — control how the badge looks in the bar. * For single and multi-select fields, a redesigned **Option visibility** section to limit which options users can pick from. {% hint style="info" %} If you previously had filters configured as inputs with placeholder text above the view, they're automatically migrated to **Quick filters** so your users see the same set of always-visible controls. Any custom placeholder you'd set (with the word "filter" stripped out) carries over as the badge's **Label**. {% endhint %} ## Search box The **Search box** is a separate control from in-app filters. Once enabled, it adds a search input that searches across every text and number field that's currently visible on the view, instead of forcing the user to set up a filter per field.
### How the Search box works **Field visibility requirements:** * The search box only searches fields that are **currently enabled and visible** in the view. * Hidden or disabled fields are not searched. * Fields must be added to the view's [display settings](/views/display.md) to be searchable. **Field type requirements:** * Only **text** and **number** field types are searchable. * Other field types (dates, relationships, attachments, etc.) are not included in search results. {% hint style="info" %} To search by a specific field, make sure it's both visible on the view and is a text or number type. You can update field visibility from the view's Fields tab. {% endhint %} ### Troubleshooting the Search box If the search box isn't returning expected results: **Search not finding results in list views** 1. Open the [list view](/views/display.md) in build mode. 2. Check that the field you're searching for is enabled and visible. 3. Verify the field is a text or number type. 4. If the field was hidden, enable it in the view settings. 5. Test the search again. **Search not working in table views** 1. Open the [table view](/views/display.md) in build mode. 2. Ensure at least one text or number field (like "Name" or "ID") is visible. 3. Add searchable fields to the table if none are present. 4. Save and test again. **General tips** * Verify the field is **visible** in the current view's configuration. * Confirm the field type is **text** or **number**. * Check that you're searching in the correct view. * Refresh the page if you've just changed the configuration. * Use [in-app filters](#overview) for non-text/number fields or more complex filtering needs. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://guides.noloco.io/views/filter-fields.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.