For the complete documentation index, see llms.txt. This page is also available as Markdown.

📲In-app Filtering

Canonical page for end-user filters on a list. Builder filters (the working set) stay on Filtering, Sorting, or Grouping. Identity vs restriction: Data restriction vs filters.

What this is / when to use it

In-app filters are chips or pickers users change at runtime.

Type
Enum
What the user gets

Dynamic

DYNAMIC

Every distinct value currently in that field (across rows they can see)

Pre-defined

PRE_DEFINED

Only the chips you configured

Use PRE_DEFINED when the business has two or three statuses. Use DYNAMIC when the field is a growing set (client names, cities).

When not to: hiding another client’s rows. That is data restriction.

Before you start

The list screen exists. The field is synced. Name length ≤ 100 characters.

Build it

  1. Open the list → In-app filters.

  2. Add a filter. Name it (“Status”).

  3. Pick the field. Pick DYNAMIC or PRE_DEFINED.

  4. For pre-defined, add the values users may tap.

  5. Publish. As an end user, tap a chip. Confirm the list narrows.

Every control

Control
Options
What it does

Type

DYNAMIC / PRE_DEFINED

Value source

Field

Sheet field

What you filter

Name

≤ 100 chars

Chip group label

Pre-defined values

List

Allowed chips

Scan is a different feature: Barcode/QR.

What users see

A filter bar. Dynamic shows values from visible rows only (restriction already applied). Clearing chips returns the builder-filtered working set.

Limits and plans

Dynamic on a huge text field is noisy. Prefer a select. In-app filters do not bypass restriction.

Example

Requests list: PRE_DEFINED Status = Open / In review / Done. Staff “All clients” list (restriction disabled): DYNAMIC on Client.

Fix problems

Symptom
What to do

Chip missing a value

Dynamic: no visible row has it. Pre-defined: add the value.

User sees another tenant

Restriction off. Not an in-app bug.

View types. Data restriction vs filters.

Last updated