Roles and permissions
What each role in a workspace may do.
Every member has one role in the workspace. A role is a fixed set of permissions; there is no per-member customisation.
| Administrator | User | Client | |
|---|---|---|---|
| See the workspace's sites | all | all | only the attached clients' |
| Site pages: plugins, themes, core, health, security, performance, reports, notes, regression | yes | view | view |
| Update rounds | run, roll back, delete | view | view |
| Backups, restores, recoveries | create, restore, delete | view | view |
| Log in to a site | yes | yes | no |
| Add, edit, delete sites; sync; sitemap | yes | no | no |
| Notes and regression pages | create, delete | view | view |
| Clients and packages | manage | no | no |
| Team, invitations | manage | no | no |
| Workspace settings, API keys, billing | manage | no | no |
Two of the three roles are read-only on the platform by construction: user and client hold view permissions and, for the user, the site login; every change — an update round, a backup, a restore, a site's settings — is an administrator's. Selecting many sites in a list gives nobody more than they have on one site.
The difference between the two read-only roles is scope and the login: a user sees the whole fleet and may open a site's admin through the dashboard; a client sees the attached clients' sites and may not. The login was removed from the client role deliberately — it hands out an administrator session on the site itself, which is the opposite of read-only.