📲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.
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
Open the list → In-app filters.
Add a filter. Name it (“Status”).
Pick the field. Pick
DYNAMICorPRE_DEFINED.For pre-defined, add the values users may tap.
Publish. As an end user, tap a chip. Confirm the list narrows.
Every control
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
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.
Related
Last updated