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.

Related

View types. Data restriction vs filters.