Collaboration
Team and roles
Who can see what, who can write, and how project access differs from org access.
Access works at two levels, and the difference matters.
Organisation roles
Settings → Team. Everyone in your workspace has one org role.
| Role | Can |
|---|---|
| Owner | Everything, including billing and deleting the org |
| Admin | Manage projects and members; not billing |
| Editor | Create projects, generate, push |
| Viewer | Read only |
Project roles
Project → Members. These override the org role for that project, and add two roles that only make sense per project.
| Role | Can |
|---|---|
| Owner / Admin | Everything in the project, including membership |
| Editor | Generate, push, capture snapshots |
| Data fabricator | Generate and push, but not change project settings |
| Approver | Review and approve runs; not run them |
| Viewer | Read only |
Data fabricator is for people who need to produce data but should not reconfigure the project. Approver is the counterpart: sign-off without the ability to push.
The rule that surprises people
A project with no member list is visible to your whole organisation.
The moment you add one member, it becomes restricted to that list. There is no separate "make private" switch; adding the first member is the switch.
This applies everywhere, not just the UI. A project you are not on will not appear in your history, your snapshot lists, or anything you fetch through the API, even though you are in the organisation.
Inviting people
Settings → Team → Invite. They get an email with a link. Invitations expire after seven days, and you can revoke one before it is accepted.
Approvals
Where a workspace wants sign-off before data is written, a push can be gated on an approval.
The flow: someone requests a run, an approver approves or rejects it, and the approved request is then consumed by the push. States are pending, approved, rejected and consumed. Approvals in the sidebar shows the queue.
Consumed matters: an approval is good for one run, not a standing permission.