🔍Data restriction vs dynamic user filters vs per-list disable
Canonical page for the data half of “who sees which rows.” Users → Data Restriction stays the Users-rail entry and should link here for the comparison. List filter how-to stays short.
What this is / when to use it
Three different features are easy to mix up.
Data restriction (personalization)
Users
Every list/details/form on that database only shows rows that match the logged-in user (or their linked fields)
Client should never see another client’s rows
Dynamic user property filters
List screen filters
A list filter whose value comes from the logged-in user’s properties
One list should be “my region” without turning on global restriction
Per-screen / per-list disable
Screen or component
Turns off data restriction for that screen or nested list
A staff directory must show everyone even though restriction is on
Builder filters
Screen
Fixed conditions (Status = Open)
Working set, not identity
In-app filters
Screen
DYNAMIC (all values in the field) or PRE_DEFINED (chips you define)
User-driven narrowing
When not to stack all five: pick the coarsest control that is safe. Restriction first for tenancy. Then list filters. Then in-app filters for convenience.
Before you start
The app is private and the Users database is linked.
A property on the data database can match a user (email, relation to Users, or a shared select like Region).
You have a Staff role that may need the disable switch.
Build it
Data restriction
Open Users → Data restriction.
Choose the matching fields (user email → row email, or user ↔ relation).
Publish. View as a client. Confirm they only see their rows.
Dynamic user filters on one list
Open the list → Filters.
Add a filter, set the value source to the logged-in user’s property (see the how-to Filter List Screens by Logged-in User Properties).
Do not also enable restriction on that database unless you want both.
Disable restriction on one screen
With restriction on, open the staff list.
Enable Disable data restriction on this screen (product help deep-link).
View as staff: all rows. View as client on a different screen: still restricted.
In-app filters
Add an in-app filter.
DYNAMIC— users pick any value that exists in the column.PRE_DEFINED— you define the chips (Open / Closed). Users cannot invent a third chip.
Every control
Restriction fields
User field ↔ row field
Tenancy.
Disable on screen
On / off
Staff exceptions.
Disable on component
Nested list
Data-to-data nested lists can inherit or disable.
Filter source
Exact / current user property
Builder filter.
In-app type
DYNAMIC / PRE_DEFINED
End-user chips.
In-app name
Max 100 chars
Label.
Data-to-data nested lists: a details screen can show a related list. That nested list honors restriction unless you disable it on the component. Reload on the nested list is the relation “show reload button.”
What users see
Clients see “their” rows only when restriction is on. Staff on a disabled screen see the working set from builder filters. In-app chips only narrow what is already allowed.
Limits and plans
Restriction is not navigation. Hidden screens are a different control.
Guests have no user record. Restriction treats them as empty — usually they should not see the screen.
Dynamic user filters need the property on the Users database. Identity dual-write can keep that property fresh. See Identity admin.
Example
Deliveries restricted by Client relation = logged-in user’s Company.
Client list: restriction on, in-app
PRE_DEFINEDStatus.Staff “All deliveries”: restriction disabled on that screen, builder filter none, in-app
DYNAMICClient.Details nested “File versions”: inherits restriction so a client never sees another client’s files.
Fix problems
Client sees everyone’s rows
Restriction off, or disable left on
Turn restriction on. Check disable.
Staff sees nothing
Restriction on, no disable, user not matched
Fix the match fields or disable the staff screen.
Filter how-to and this page disagree
How-to is the short job
This page is the comparison.