Collaboration

Roles and permissions

Organisation roles and project roles — what each level decides, how access to an organisation project is worked out, and how a plan can clamp what a role can do.

SpaceSync has roles at two levels, and they answer different questions. Organisation roles decide what you can do to the organisation — its members, teamspaces and settings. Project roles decide what you can do to a piece of work. Personal projects have project roles only.

Organisation roles

Owner: One per organisation. Everything an Admin can do, plus sign-in and security settings and transferring ownership. Cannot leave without transferring first.
Admin: Manages members, guests, invitations, teamspaces, verified domains, the organisation's projects, the audit log and usage. The day-to-day administrative role.
Member: A normal user. Creates projects at the organisation's root or in a teamspace they belong to, and works in the projects they can reach.
Guest: An external reviewer, client or consultant. Sees only the projects they have been given explicitly, is in no teamspace, uses no seat, and creates nothing.

Admins manage the organisation's projects from the admin list — reassigning owners, moving them, deleting them — but an admin role does not by itself open a project. If a project's access is set to *No access* and you hold no grant on it, you can see it in the admin list and not on the canvas. See Organisations.

Project roles

Owner: The project's owner. Can invite, change roles, manage the share link, transfer, archive and delete. In an organisation, ownership is reassigned by the owner or an admin rather than transferred.
Editor: Works on the project — draws, edits the programme, comments, saves versions.
Viewer: Reads the project. Cannot change it.

How access to an organisation project is worked out

On a personal project, you are on it because you own it or someone invited you. On an organisation project there are more ways in, and you get the highest role any of them gives you:

Everyone at the organisation — the project's default access: *Can edit*, *Can view* or *No access* for every member. Guests are never covered by it.
The teamspace the project lives in — its members can edit.
A teamspace grant — a teamspace given Editor or Viewer on a project that lives elsewhere.
An individual grant — you were added by name, or invited as a guest.

The sharing panel shows each of these as a row, so you can see why a given person has the access they have. Organisation projects walks through setting them.

Where the answer actually lives

SpaceSync does not decide what you can do by looking up your role name in a table. The server computes your capabilities for each project directly and sends them with the project — the interface then renders exactly those. A button you cannot see is a capability the server did not grant, not an oversight.

That is why this page does not publish a role-by-role grid: it would be a second answer to a question the product deliberately answers in one place. If you need to know whether a specific person can do a specific thing, open the project's member list — it reflects the real computation.

When your plan clamps your role

An effective role can be lower than an assigned role

Your plan can restrict what a role is allowed to do. When that happens your effective role is lower than the one you were given, and the interface says so — offering an upgrade when the limit is the plan, and *"ask the project owner"* when the limit is genuinely your role. On an organisation project the organisation's plan counts too: if it is on Pro, so are you there, whatever your own plan.

The distinction matters when you are troubleshooting: an owner who cannot edit is almost always looking at a plan limit, not a permissions bug. See Plans.