Roles and permissions

Access in Workover is set at three levels — the workspace, the project, and the individual document. Most confusion comes from mixing them up, so this page separates them.

Workspace roles

Everyone in your workspace holds one of these.

Owner — full control, including billing and the workspace itself. There is always exactly one, and the role cannot be taken from them by an admin.
Admin — manages members, projects and settings. Can do almost everything an owner can, except act on the owner.
Member — works on the projects they have been given, and cannot manage the workspace.
Guest — not really a workspace citizen at all. Guests exist because they were shared into specific documents; they see those and nothing else.

Owners, admins and members each occupy a seat. Guests do not. See members and seats — the billing boundary is not where most people expect it.

Project access

Being in the workspace does not, by itself, get you into a project. People are added to projects individually, and a project is the natural place to draw a line — it holds one site and everything destined for it.

Anyone with access to a project can work on its documents. Note that project access costs a seat, even for someone who is not a workspace member.

Document roles

A single document can be shared with specific people, independently of the project. Four roles:

Owner — the person who created it. Not assignable; there is exactly one.
Editor — can change the content, and can share the document onwards.
Commenter — can comment and suggest, but cannot change the text directly. The right role for a reviewer.
Viewer — can read, and nothing else.

A workspace or project member already holds editor on the documents in their projects, so you only need to share explicitly when you are reaching outside that.

How the levels combine

Access is the most permissive of the three. Someone who is a project member and also shared into a document as a viewer is still an editor, because the project grants it — sharing a lower role does not take away access that already exists elsewhere.

To genuinely restrict someone, remove the broader grant. Narrowing the document share will not do it.

Editors and above. If you can change a document, you can share it — which is deliberate, so getting a second pair of eyes never requires an admin.

There is a per-document switch to turn that off when a document should only be shared by its owner.

What guests cannot reach

A guest sees the documents shared with them. They do not get the project’s document list, the site connection, other people’s documents, workspace settings, billing, or the member list. They cannot publish to WordPress.

This is enforced in three places rather than one — the API, the collaboration server, and the real-time sync layer — so a guest cannot reach a document by guessing a URL or by opening a socket directly.