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. Nothing happens until both 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
35
permissions to tick, in 6 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. 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.
Where it stands
Good to know
- Handing over a workspace
- Ownership cannot be transferred. Owner is always the account the workspace belongs to.
Questions
Asked often
Keep going
Works well with
Start
Your domain,
your mail.
Point a domain at OpenEmail and read it in a mailbox built around it. The free plan covers one domain.
