If none of the five built-in roles matches how your team works, build one.
The permission groups
Permissions are grouped by the area they affect:
- Websites. Viewing, adding, removing, re-scanning, verifying ownership.
- Scans. Viewing results, scan history, downloading reports, requesting an expert review.
- Team. Viewing members, inviting, removing, changing roles.
- Billing. Viewing billing, managing the subscription and payment method.
- Workspace. Viewing settings, editing settings, exporting workspace data.
- Support. Viewing, creating and replying to support tickets.
- Service requests. Viewing requests and responding to quotes.
- API. Managing API keys.
Building one
- Open Team, then the roles area.
- Create a role and give it a name people will understand. "Content editor" tells a colleague more than "Custom role 2".
- Tick the permissions it needs.
- Save, then assign it to people as you would any other role.
Two traps
Viewing and doing are separate. Someone who can re-scan but cannot view results will have a strange time. When you grant an action, check the matching view permission is on too.
Start from what they need, not from a full list with things removed. It is easier to reason about, and you will not leave something on by accident.
Starting over
If your roles get into a mess, you can reset them to the defaults. This returns the built-in roles to their original permissions, so review what you have built before using it.
A worked example
A content editor who should fix alternative text and link text but never touch infrastructure or money: view websites, view scan results, view scan history, download reports. Nothing from Team, Billing, Workspace or API.