Skip to content
Documentation

Team and roles

A role governs organisation-level concerns — billing, the team, who can create a workspace. It is not what decides whether someone can open a particular workspace; that is a sharing rule.

The four roles

RoleWhat it governs
OwnerEverything an admin can do, plus renaming the organisation. Held by whoever created it, and it is not an invitable role — an owner cannot change their own role.
AdminFull access, including billing, the team, and every workspace — admins hold Manage on all of them implicitly.
MemberWorks in the workspaces shared with them, and creates API keys.
Read-onlyViews the workspaces shared with them. Cannot change anything.

Owners and admins are the only roles that reach the team and billing pages. Everyone else works inside the workspaces they have been granted — see sharing a workspace.

Admin needs Silver

The admin role can only be assigned once the organisation has reached the Silver tier, which is $50 of net lifetime spend. The reason is blast radius: an admin can spend the organisation’s balance and see every workspace in it.

The gate is on assignment only. An organisation that drops below Silver keeps the admins it has — nobody is silently demoted — it simply cannot appoint new ones until it is back above the line. See tiers and limits.

Inviting people

Invites take one or more email addresses at a time, comma-separated, with a single role for the batch and an optional message. Invited people appear in the same list as members, marked as a pending invite, so the team page is one picture rather than two.

  • Resend an invite whose email did not arrive — this is also the fix when the invite was created but delivery failed.
  • Cancel one that should not have been sent.
  • Invites expire. An expired one shows as expired in the list and needs resending rather than chasing.

The team page also shows how many members are active, along with a seat limit if your organisation has one.

Managing a member

From a member’s row you can:

  • Change their name — how they appear to the rest of the team.
  • Change their role, subject to the admin gate above.
  • Deactivate them, which keeps the record and the history but ends their access. This is usually what you want when someone leaves.
  • Remove them outright.
  • Set a password for them, for accounts that do not use a provider to sign in.

Removing someone does not remove their work. The documents they uploaded and the tables they built belong to the workspace, and the corrections they made stay attributed to them — which is the point of recording who changed a cell in the first place. See corrections.