Skip to main content
You create roles, assign them to workspace members, and write rules for which roles can read/create/update/delete records in each table — optionally filtered to specific rows. Because the rules live on the database rather than in any one app, every app and workflow enforces the same policy.

​
Roles

  • Assigned manually to workspace members (not condition-based).
  • All team members is built in — every internal member has it.
  • Roles govern the central database only. App access is controlled by workspace membership, not roles.
External app users bypass roles. A public app must expose only what its users should see — scope every query to the signed-in user. See Authentication.

​
Rules

Rules live in zite.permissions.json at the workspace root. Each rule grants (or denies, via effect: "deny") a set of operations to one or more roles, with an optional rowFilter comparing a record field to a userField (from the signed-in user) or a staticValue. See the permissions file reference for the full schema.

​
How access is decided

For a user, operation, and table:
  1. No rules → the workspace defaultPolicy (allow by default, or deny to lock down).
  2. Only rules matching the operation and one of the user’s roles count; none matching → denied.
  3. An unscoped deny rule blocks access and beats any allow.
  4. Otherwise matching allow filters are OR’d (deny filters AND’d) into the visible row set.
Permissions are table- and row-level (no field-level). Set them in the dashboard roles UI or let an agent manage zite.permissions.json; they’re enforced on every database call, including the Database API.