Trust

Roles and permissions

Four roles, ranked, and fixed. This page says what each one can do, so you know what you are handing over before you invite somebody.

Last updated 2026-08-14

The four roles

Every member of an account holds exactly one of these. They are ranked, and each one can do everything the role below it can do, plus its own additions.

RoleWhat it owns
OwnerThe account: billing, company details, and the subscription.
AdminConfiguration: sending domains, sender identities, API keys, workspaces, the team, and anything that changes deliverability.
EditorThe work: contacts, lists, templates, sequences, campaigns, and sending.
ViewerNothing. Reads everything, changes nothing except their own profile.

Reading is open to every member for the working data: contacts, templates, sequences, campaigns, analytics and the suppression list are all visible to a Viewer. What the roles mostly divide is who can change things.

Three things are an exception, and they are read-restricted rather than merely write-restricted. API keys are visible only to an Admin and above, since listing them is most of the way to auditing your own credentials. Company details and billing receipts are visible only to the Owner. So an Admin configures sending and the team but does not see the invoices, and a Viewer sees the work without seeing the keys.

Viewer

Read-only. A Viewer can look at all the working data in the account, everything except the API keys and the billing records noted above, and can change only their own account: their profile, their password, and which workspace they are currently looking at.

A Viewer cannot send email. That includes single sends, transactional sends and bulk sends. Sending spends the account's monthly allowance and stakes the sending domain's reputation, and a bulk send reaches the whole audience in one action, so sending starts at Editor.

Editor

Everything a Viewer can do, plus the day-to-day work of running email. An Editor can:

  • Create, update and delete contacts, one at a time or in bulk, add and remove their tags, and record events against them
  • Create, rename and delete tags
  • Create, update and delete lists, and add or remove the contacts in them
  • Create, update and delete templates, and restore an earlier version of one
  • Build and edit sequences, including their steps and the connections between them, and activate a sequence
  • Enroll contacts in a sequence individually or in bulk, and pause, resume, retry or cancel those enrollments
  • Create, update, delete, schedule, send, pause and cancel campaigns
  • Upload images and files for use in email
  • Run the AI setup, including activating a sequence it generated
  • Send email: a single send, a transactional send, or a bulk send
  • Suppress an address, and unsubscribe a contact

Note the asymmetry in that last line. Adding a suppression is an Editor action, because it only ever stops mail. Lifting one is an Admin action, for the reason in the next section.

Admin

Everything an Editor can do, plus the configuration that decides how and whether the account can send at all. An Admin can:

  • Add, verify and remove sending domains
  • Configure sender identities, set the default one, and delete them
  • Create, update and revoke API keys
  • Create, update, archive and unarchive workspaces
  • Invite a teammate, change a teammate's role, and remove a teammate
  • Lift a suppression, and handle bounce and complaint records
  • Delete uploaded files

Lifting a suppression sits here rather than with Editor because a hard suppression, meaning a bounce or a spam complaint, applies across the whole account and lifting it also removes the address from our sending provider's own list. That is a deliverability decision rather than a content one, and getting it wrong is how a sending domain gets blocklisted.

Owner

Everything an Admin can do, plus the account itself: the company details, and the subscription, which covers starting checkout, opening the billing portal and ending a trial.

The person who registers the account becomes its Owner, and there is exactly one. Ownership cannot currently be transferred. There is no way to hand the Owner role to somebody else, and no way to promote a second person into it. Worth planning around when you set the account up: whoever signs up should be whoever should still own it in a year.

The three rules that surprise people

These are the ones worth knowing before you plan around them, because each is a limit rather than a setting.

Roles are account-wide. There is no per-workspace role and no per-workspace membership. An Admin is an admin in every workspace in the account, and an Editor is an editor in every workspace. If you run several products as separate workspaces, be aware that inviting somebody into one of them gives them their role in all of them. This is also why SendHeron is not an agency tool yet: there is no such thing as a client login that sees one workspace only.

You can only invite or promote below your own level. An Admin can invite an Editor or a Viewer, but cannot create another Admin. An Admin also cannot change another Admin's role or remove them, because that is acting on somebody at their own level rather than below it. Nobody can change the Owner's role, and the Owner role cannot be assigned to anybody.

A Viewer cannot send. Covered above, and repeated here because it is the one people are most often caught by: a Viewer who has been asked to "just send the newsletter" cannot, and needs Editor to do it.

Roles are not API key scopes

These are two separate systems and it is worth not confusing them. A role belongs to a person and governs what they can do in the dashboard. An API key carries scopes instead, and a request is allowed or refused on the scopes the key holds, not on the role of whoever created it.

The one place they meet is that creating and revoking API keys is an Admin action. So an Admin decides which keys exist and what each one may reach, and after that the key stands on its own.

Changing somebody's role

An Admin or the Owner can change a teammate's role, within the limits above. One consequence is worth expecting: any role change revokes that member's sessions, promotions included, so they are signed out the next time their session refreshes rather than the instant you save it. Promoting somebody who is mid-task will sign them out shortly afterwards, and that is working as intended rather than a fault.

Roles are fixed. There are no custom roles, and the permissions attached to each role are not configurable.