Roles & permissions levels
What they may do, and where.
A role says what somebody may do. An address grant says where they may do it, unless the role reaches every address. Nothing happens until the what and the where agree.
In short
What is role-based access control?
Role-based access control gives each person a named role, like Admin or Viewer, rather than permissions set one person at a time. Change the role and everyone holding it changes with it.
6
roles every workspace starts with
24
more you can write yourself
53
permissions to tick, in 8 groups
How it works
Six roles in every workspace
Owner, Admin, Member and Viewer form a ladder, each holding everything below. Beside it, Developer builds integrations without reading mail, and Billing runs the plan.
Write up to 24 of your own
Tick from one grouped list. Editing templates ticks reading them, and unticking the read takes the edit with it.
A role is a ceiling for keys
Issue a key against a role and it keeps only the scopes both hold, checked on every request. Narrow the role and the key follows without rotation.
What you get
In the product today
Owner stays fixed
Holds every permission, later ones too, and cannot be edited, deleted or given.
Rename the rest
Call them Ops and On-call if that is how your team talks.
Deleting asks first
Delete a role people or keys still hold and it asks where they move.
Assistants obey it
A viewer's MCP client is built without a sending tool.
Good practice
Getting the most out of it
- 01
Share the address too
A role gives nobody an address unless it reaches every address. Otherwise share each one as Can send or Read only.
- 02
Cap every key
Issue each API key against the role whose job it does.
- 03
Describe the job
Whoever hands the role out next decides from its description, so say what it is for.
Questions
Asked often
Keep going
Works well with
Start
Your domain,
your mail.
Point a domain at Nextmail and read it in a mailbox built around it. The free plan covers one domain.
Google Workspace
Fastmail