> ## Documentation Index
> Fetch the complete documentation index at: https://developers.zite.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles & permissions

> Define roles and row-level rules once per workspace. Every app and workflow enforces them.

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.

<Warning>
  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.
</Warning>

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](/framework/permissions-file) 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](https://app.zite.com) 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](/api/overview).

### 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](/framework/schedules).
* A workflow is triggered as a [webhook](/framework/webhooks).
* A Zite organization administrator or workspace editor is using an internal app. They can read and write any table, regardless of rules.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.