Skip to main content
Roles and data-access rules for a workspace live in a zite.permissions.json file at the workspace root. This is the schema reference; for the concepts and evaluation model, see Roles & permissions.

​
Structure

​
Fields

  • version — always "1.0".
  • defaultPolicy — what happens on a table with no rules: allow (open, the default) or deny (locked unless a rule grants access).
  • roles — each role has a stable id and a display name. Rules reference roles by name; the id survives renames so member assignments never break. The built-in role { id: "builtin:all-team-members", name: "All team members" } applies to every internal member.
  • tables — keyed by the table’s SDK name (PascalCase). Each entry has a rules array.

​
Rules

  • roles — the role names this rule applies to.
  • operations — any of read, create, update, delete. Listing several is shorthand for one rule per operation.
  • effect — allow (default) or deny.
  • rowFilter — restricts which rows the rule covers (like a Postgres USING clause).

​
Row filters

A comparison filter compares a record field to either a value from the signed-in user (userField) or a fixed staticValue — exactly one of the two — using eq, neq, contains, gt, gte, lt, or lte. Compose comparisons with and, or, and not. userField can reference the base user fields (id, email, firstName, lastName) plus any fields synced from your users table.

​
Example

Here every team member can read only the orders they own, while Managers can read, update, and delete all orders. Because defaultPolicy is deny, any table without rules is fully locked down.
Permissions are table- and row-level and govern the workspace database. There are no field-level permissions, and external app users bypass roles entirely — see Roles & permissions.