MailSlurp logo
Search documentation

Roles and permissions

Design least-privilege access for MailSlurp using custom roles and per-user permissions.

View MarkdownAgent setup

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

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

  1. Keep the number of high-privilege users small.
  2. Separate production access from general day-to-day testing access.
  3. Review permissions when people change teams or responsibilities.
  4. Use temporary elevated access only when it is genuinely required.
  5. 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.

SAML role assignment

For SAML-managed teams, MailSlurp can assign roles when users sign in through your identity provider. Configure a SAML default role for baseline access, or map SAML claim values such as Entra app roles, Entra group IDs, or Okta groups to specific MailSlurp roles.

Use claim-to-role mappings when the identity provider should decide access. For example, a MailSlurp.PTEST.User app role can map to a MailSlurp role with only PTEST permissions, while a different app role maps to a development environment role. Keep the MailSlurp role permissions narrow, then assign users to the matching IdP role or group.

When you use Environments, those same roles can control environment access. Grant the organization access to an environment, then restrict that grant to the role that should be allowed into it. This lets a SAML user mapped to a DEV role see the DEV environment without also seeing PTEST, STEST, or VTEST.

For provider-specific examples, see Entra SAML role mapping and Google Workspace SAML role mapping for full group-claim setups.