Members, roles and project permissions
The four roles a workspace member can hold, how a project narrows permission down to one set of tables and dashboards, invite links and QR codes, and a project's own API-Key.
Permissions belong to the team edition. The desktop app is single-user and has no roles at all.
Workspace members and their roles
Setting → members in the sidebar lists display name, nickname and role. Members are added from the instance's members, or through a generated invite link.
| Role | What they can do |
|---|---|
| Administrator | Everything: workspace settings, members, creating and deleting tables and dashboards |
| Editor | Create tables, edit data, write formulas, build views and dashboards |
| Viewer | Look only |
| User | Use the dashboards and forms prepared for them — entering and querying — without changing structure |
The line printed on that page is the heart of the model: a workspace member holds their role over every resource and project in that workspace.
Projects narrow it
When somebody should not see the whole workspace, use a project: create one in the sidebar, move a subset of tables and dashboards into it, and give the project its own members. A project member holds their role over the resources in that project only.
A project also offers: previewing it as a viewer would see it, project information, its own API-Key (so a Data API call uses the project's key rather than the workspace's), a distinction between connections inside and outside the project, and dissolving it.
How many projects you may have depends on the plan.
Invite links and QR codes
Adding a member offers an invite link: choose the role, copy the link or show its QR code, and send it. Opening it joins the workspace (or the project) with that role. The link carries the invitation, so refreshing it invalidates the old one — that is how you take an invitation back when somebody leaves.
The collaborator cap
An instance's collaborator count follows its plan — the team tier starts at 40 people, business at 100, enterprise to order. At the cap, adding somebody says so.
Arrangements that work
- One workspace for the company, a project each for finance and sales, each department's tables inside their project and project permission only for their own people.
- Dashboards for everyone but tables nobody may edit: tables in a project, dashboards in the workspace, workspace members set to viewer.
- Data entry on the ground: the user role plus a form view, or a public form.