Limit document access by field value
Row-level-style security: one global field becomes the boundary, each user gets the values they may see, and everything else silently disappears — including the three semantics you must know before trusting it.
Before you begin
- A global field whose values map cleanly to who-may-see-what (branch, region, client)
At the end of this guide, one field draws a boundary through your documents — each user sees only the documents whose value matches theirs, everywhere: search, browsing, queues — and you'll know the three semantics that decide whether the boundary actually holds.
Document-type permissions answer "can this person use invoices?" This feature answers the sharper question: "which invoices?" — by branch, region, client, whatever one global field encodes.
Turn it on
Administration > System Settings > Document-Properties Settings:
- Enable User-based Global Field for Limiting Document Access
- Global Field for Limiting Permissions — pick the field that carries the boundary value.
- Optionally Hide folders in the Folder Browser when there are no files within the folder viewable by the user — so restricted users don't browse skeletons of folders they can't open.
Save Changes.
Give each user their values
Administration > Users > open the user > Details tab. A new section appears — Limiting Document Access by Field Value for Field: your field — where you grant the values this user may see: pick from the field's list, or type values separated by semicolons. Matching is by value, case-insensitively.
The three semantics that decide everything
This feature's behavior at the edges is deliberate, and two of the three run opposite to what admins assume:
A user with no values is unrestricted. Empty doesn't mean "sees nothing" — it means "not participating in the boundary." Restricting someone therefore requires entering their values; forgetting a user leaves them seeing everything.
Administrators are always exempt. Testing the boundary from your admin account proves nothing — test as a real restricted user.
Enabled with no field chosen blocks direct document access across the board. Half-configured is worse than off: flip the enable switch and pick the field in the same sitting.
And one more property to design around: the filtering is silent. Restricted users get no "access denied" — non-matching documents simply don't exist for them, in search results, folders, and queues alike. That's the right behavior for confidentiality (the message would leak the existence), but it means "I can't find document X" from a restricted user is expected, not a bug.
How it stacks with document-type permissions
The boundary filters first; document-type permissions then apply within it — permissions can narrow further but never widen past the boundary. Design in that order: the field decides which rows, the permission grid decides what they can do with them.
Success check: give a test user exactly one value, sign in as them, and search the field for a value they don't hold — zero results, no error. Then clear their values entirely and repeat: everything visible. That second test is semantic #1 made visceral — and the reason your user-provisioning checklist now includes this field.