Sharing a workspace
Access has two layers that are easy to confuse: your role in the organisation, and your level on a particular workspace. Nearly every “why can they not open this?” question is the difference between the two.
Your role decides one thing
Your organisation role — owner, admin, member or read-only — governs organisation-level concerns: billing, the team, settings, and who may create a workspace. Creating one is a role gate for the obvious reason that there is no workspace yet to hold a permission.
After that, your role stops being the thing that answers “can I open this workspace?” The exception is admins: owners and admins hold Manage on every workspace implicitly. See team and roles.
The workspace level decides the rest
| Level | What it permits |
|---|---|
| Read | Open the workspace, read its documents and its tables. Change nothing. |
| Read & Write | The working level: upload documents, build tables, write columns, run extractions, override cells. |
| Manage | Everything above, plus the workspace’s own settings — renaming, archiving, API keys, sharing rules, and a table’s auto-mode switch. |
A workspace is private to its creator until a rule says otherwise, and sharing a workspace shares everything in it — every document and every table. There is no per-table or per-document sharing, which is the main thing to have in mind when deciding what goes in a workspace in the first place.
Three scopes, and they combine
A rule targets one of three things:
- The whole organisation — everyone, including people who join later.
- A role — every member holding it, which is how you say “all admins can manage this” without naming them.
- One person.
Several rules can reach the same person, and when they do, the highest level wins. An organisation-wide Read plus a personal Manage means that person can manage.
Why there is no “None” level
Because grants only ever add. A rule that granted nothing would look like a revocation while doing nothing at all — the organisation-wide Read underneath it would still apply. To take access away, delete the rule that gave it.
If someone still has access after you deleted a rule, another rule is reaching them: check for an organisation-wide or role-scoped grant, and remember that admins hold Manage implicitly.
What the interface shows you
The interface hides what your level would not permit, so a Read user does not see a Run button they cannot use. That is a courtesy, not the security boundary: the server checks every action again regardless of what the page offered.