Permissions
Permissions decide who can see and change what inside a project. Nobody has access to a project by default: every person is added to it explicitly, and access in one project never carries over to another.
Three layers work together:
- Members and groups: who is in the project.
- Roles and inheritance: which folders, tables, files and apps each of them can view, change or share.
- Row filters: which rows of a table they see. Enforced by the database itself.
Members and groups
A member is a person added to the project. A group bundles members and other groups, so you grant access once instead of per person. Groups can be nested: a member of Controlling is also a member of every group that contains Controlling.
Every project has three built-in groups:
| Group | Members |
|---|---|
| Project Members | Everyone in the project, automatically. |
| Editors | Members who build the project's data and apps. You add and remove members. |
| Zeit AI | Zeit AI staff in the project, automatically. Used for support and setup. |
Manage both under Project settings → Access → Members and groups. Each row shows the person's or group's own roles on the project. If they have none of their own, it shows what they get through their groups, e.g. "Viewer via groups".
Roles
You grant a role to a member or group on a resource: the whole project, a folder, or a single table, file, app or data source.
| Role | View | Propose changes on a branch | Publish changes | Manage access |
|---|---|---|---|---|
| Viewer | ✓ | |||
| Proposer | ✓ | ✓ | ||
| Editor | ✓ | ✓ | ✓ | |
| Manager | ✓ | ✓ |
- Proposer can only be granted on the whole project. Proposers work on a branch; an editor reviews and publishes their changes.
- Manager is about access, not content. An IT administrator can manage who sees what without being able to change data. To both edit and manage, grant Editor and Manager together.
- Roles add up. A person gets every role granted to them directly and to any group they belong to, including nested groups. There are no "deny" grants.
- A manager can grant roles anywhere they hold Manager, but cannot remove their own manage rights on a resource. This prevents locking yourself out.
Default access
A new project starts with these grants on the project:
| Group | Roles |
|---|---|
| Project Members | Proposer |
| Editors | Editor |
| Zeit AI | Editor, Manager |
Adjust them in Members and groups. For example, remove Proposer from Project Members and grant Viewer to individual groups instead, so that new members see nothing until they are put in a group.
Inheritance
Resources sit in the project's folder tree. A grant on a folder applies to everything inside it, including subfolders, at any depth. A grant on the project applies to everything in the project.
- Moving a resource into another folder changes what it inherits.
- Breaking inheritance: open a resource's Permissions and turn off Inherit from parent. From then on only grants on that resource itself apply; everything inside it still inherits from it. Use this for sensitive folders such as HR. First grant Manager directly on the resource to yourself or a group you are in: project-wide managers no longer reach it, and ZeitMind refuses the change if it would take away your own manage rights.
- Dependent tables are not shared on their own. Tables extracted from a file follow the file, and tables that belong to an analysis or an app follow their owner.
Sharing an app
Access to an app does not give access to the data it shows. When you share an app, also grant Viewer on the tables it reads, through each table's Permissions or a folder that contains them. Zeit AI sees a warning on apps whose users can't read all of their data and can add the missing grants in one step.
Row-level security
Roles decide which tables someone can read. Row filters decide which rows of a table they see, e.g. only the cost centers they are responsible for.
Row filters are enforced by the project database, not just by the app. Every member queries with their own database role, and no member role can bypass row filters, including editors. A mistake in the app therefore cannot show rows the database would refuse.
Member attributes
Each member can carry named attributes with one or more values, set in Members and groups:
| Member | Attribute | Values |
|---|---|---|
anna@example.com | Cost centers | 4711, 4712 |
anna@example.com | Countries | DE |
Groups have no attributes. Merging values from several groups would grant combinations no single group has. To scope a group, use a Member is condition instead (see below).
Table filters
Open a table's Security tab and turn on Filter rows. A filter is a list of policies:
- A row is visible if it matches at least one policy (OR).
- A policy matches if all of its conditions hold (AND).
| Condition | Matches a row if |
|---|---|
| Member attribute | the column's value is one of the viewer's values for that attribute |
| Fixed values | the column's value is one of the listed values |
| Member is | the viewer is one of the listed members, or in one of the listed groups |
Examples:
| Goal | Policies |
|---|---|
| Own cost centers or own personnel numbers | Cost center ∈ member's Cost centers or Personnel no. ∈ member's Personnel numbers |
| Own cost centers, only in own countries | Cost center ∈ member's Cost centers and Country ∈ member's Countries |
| Admins see every row | Member is Admins |
| Controlling sees cost center 5 | Member is Controlling and Cost center ∈ {5} |
Good to know:
- No filter: everyone who can read the table sees every row. A filter without policies: nobody sees any row.
- A member without the attribute a condition asks for does not match that condition. Attribute names and values must match exactly, so a typo silently hides rows.
- On editable tables, the same filter also limits which rows a member can add, change or delete.
- Changes to member attributes apply from the next query on. Changes to grants, groups and table filters are applied to the database in the background, usually within seconds; until then the previous rules still apply.
- The app passes each member's attributes and groups to the database as a short-lived token, signed with a key specific to the project. The database checks the signature before applying any filter, so the values cannot be forged from the browser.