Roles
Four roles in a workspace, and overrides per project.
A workspace has four roles.
The four
Section titled “The four”ownerroleFull control: billing, ownership transfer, workspace deletion, integrations, domains, permissions and publishing.
adminroleManage projects, members, integrations, domains and publishing. An admin cannot delete the workspace or transfer ownership.
editorroleCreate and edit pages, comment, draft, and submit for review. Publishing can be granted separately.
viewerroleRead private content they have access to, and comment. No editing.
Per-project overrides
Section titled “Per-project overrides”A workspace holds several sites, and people do not have the same standing in each. The person who owns the API reference is a reader of the help centre. The support lead who writes the help centre has no business in the API docs.
Set a role per project to say that.
Without overrides the only way to express it is two workspaces, which splits the people list, the audit trail and the billing relationship in order to make a statement about one project.
Warning
An override is an override, and the direction matters. Access comes from the workspace: a project role means nothing for somebody who is not a member, and removing them from the workspace removes them from every project at once.
A project row that kept somebody in after they were removed is the shape of every “why can they still see it” incident.
Per-project roles are a Business capability. See Plans.
The owner floor
Section titled “The owner floor”A workspace always has at least one owner. The last owner cannot be demoted or removed; you transfer ownership instead.
This is enforced rather than advised. A workspace with no owner is a workspace nobody can bill, rename or delete.
Two-factor authentication
Section titled “Two-factor authentication”An owner can require two-factor authentication for the whole workspace.
Enrolment is the gate rather than rejection: somebody without it is taken to enrol at their next sign-in and never told “no”, and an existing session is untouched. Turning the requirement on does not lock out the person who turned it on.
Both workspace.two_factor_required and workspace.two_factor_optional are
recorded in the audit log.
What a role does not control
Section titled “What a role does not control”Publishing is a merge in your repository. A role decides who can commit through Staleless; your branch protection decides who can merge. Set both.