Roles and permissions
Good MailSlurp governance starts with clear access boundaries. The goal is simple: give each person the access they need for their job, and no more.
How to think about access
MailSlurp organizations support custom roles and per-user permissions. That means you can shape access around responsibilities instead of forcing every user into one broad shared role.
Typical access differences include:
- who can manage organization settings
- who can invite or remove users
- who can manage sign-in policy and SSO
- who can create, view, or modify inboxes, phone numbers, and domains
- who can review monitoring and campaign-quality workflows
Recommended role patterns
Platform and admin owners
Use for the small set of people who manage production sender setup, environments, access policy, and high-risk operational changes.
QA and release operators
Use for people who need to create or inspect testing resources, run audits, and review launch readiness without broad organization admin rights.
Marketing and lifecycle reviewers
Use for people who need campaign review, probe, preview, or monitoring access without deeper infrastructure controls.
Data and operations users
Use for people who need webhook, forwarding, and structured-content workflows but do not need broad account administration.
Practical rules that prevent trouble
- Keep the number of high-privilege users small.
- Separate production access from general day-to-day testing access.
- Review permissions when people change teams or responsibilities.
- Use temporary elevated access only when it is genuinely required.
- Pair permission changes with your own audit and review process.
Shared resource guidance
When resources are intentionally shared across a team:
- make the access explicit
- keep ownership clear
- avoid using one broad admin permission set to solve every sharing problem
For stronger separation, combine permissions with Environments so the same people do not automatically see both staging and production resources in one workspace.