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).
  • Two built-in roles exist on every workspace: All users, which matches everyone who can reach an app including anonymous visitors, and All team members, which matches members of your Zite organization only.
  • Roles govern the central database only. It’s governed no matter wheter it’s accessed from an internal or external app. App access is controlled by workspace membership, not roles.

​
Turning roles on

Rules live in zite.permissions.json at the workspace root, but nothing in that file is enforced until defaultPolicy in that file is set to "deny". That single field is the workspace’s master switch.
With defaultPolicy absent or set to "allow", the entire file is inert: no rules within it are enforced. Set "defaultPolicy": "deny" to turn roles on.
You can turn roles on from the Roles tab on the Members page, which writes that field and will analyze your apps to find the proper set of rules to start with.

​
Rules

Once roles are enabled, every table is locked down by default, except for administrators of your Zite organization or editors of the workspace. You must write rules to grant access to each table and operation. Each rule grants one roleId one operation on one table, 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. Roles off (defaultPolicy is not "deny") → every access (read and write) is allowed. The file is ignored entirely.
  2. No rules for the table → denied, because roles being on means deny-by-default.
  3. No rule matching both the operation and one of the user’s roles → denied.
  4. Otherwise allowed, and the row filters of the matching rules are OR’d into the visible row set. A matching rule with no rowFilter grants every row.
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 done by a user, including the Database API.

​
Rule evaluation exceptions

There are a few exceptions when rules are not in effect, even when roles are on. Access to the database is allowed unrestricted in the following cases:
  • A workflow run that was triggered by a schedule.
  • A workflow is triggered as a webhook.
  • A Zite organization administrator or workspace editor is using an internal app. They can read and write any table, regardless of rules.