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, and 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, so 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.