Members, roles and permissions

Every person you invite into an Auralis workspace holds exactly one role, and that role decides what they are allowed to do. There are four roles. From least to most powerful they are viewer, editor, admin and owner.

The roles are strictly cumulative. An editor can do everything a viewer can do, an admin can do everything an editor can do, and an owner can do everything an admin can do. There is never a permission that a lower role holds and a higher role does not, which means you can always promote somebody to solve a permission problem without worrying about what the promotion takes away.

Choosing a role

Viewer is read-only. A viewer can open the inbox, read any ticket in the workspace, read the conversation history, look at customers and companies, browse help-centre articles and open dashboards and reports. A viewer cannot reply to a customer, cannot change a ticket and cannot create anything. This is the right role for somebody who needs visibility into the support queue — a manager watching volume, or a colleague in another department who needs to look things up — without becoming another voice in the customer's inbox.

Editor is the working agent role, and it is the role most of your team should have. An editor does all of the day-to-day support work: creating tickets, replying to customers, adding internal notes, changing status and priority, assigning tickets to people and to teams, merging, splitting, snoozing and reopening tickets, logging time, managing to-dos, and running bulk updates across many tickets at once. Editors also build the tools the team works with — macros, canned responses, saved views, SLA policies, teams and squads — and they write and publish help-centre articles.

Admin adds the workspace-configuration layer on top. Admins manage people: they invite new members, change other members' roles, and remove members. They configure channels such as email and the web widget, manage integrations, webhooks and API keys, configure automation, and change workspace settings. Admins can also read the audit log, review active sessions and revoke them, and see billing. One useful way to remember the split is that an editor changes the work, an admin changes the workspace.

Owner is the top of the ladder and, in almost every respect, identical to admin. There is no everyday task that an owner can perform and an admin cannot. The role exists for two specific protections described below.

What is genuinely owner-only

Two rules make the owner role more than a label.

First, nobody can grant a role higher than their own. An admin can create viewers, editors and other admins, but an admin cannot make anyone an owner. Only an existing owner can. This stops workspace administration from being a one-way ratchet in which anyone with member-management rights can promote themselves to the top.

Second, the last owner cannot be demoted or removed. If a workspace has exactly one owner, attempts to change that person's role or delete their membership are refused. This guarantees that a workspace can never be left with nobody able to mint a new owner.

Beyond those two rules, treat owner and admin as the same level of trust when you are deciding who gets what.

A closer look at the boundaries

A few of the boundaries surprise people, so they are worth stating plainly.

Deleting is usually a step above creating. An editor can create and edit teams, squads, macros, canned responses, saved views and SLA policies, but deleting any of those requires an admin. The same applies to customers and companies: editors create and update them, admins delete them. The reasoning is that creating a macro is recoverable and deleting one silently changes what everyone else's tickets do.

Tickets are the exception to that pattern. Editors do the whole ticket lifecycle including deleting an internal note, because ticket work has to be fast and every action on a ticket is recorded on the ticket's own timeline anyway. Note that only internal notes can be deleted — a reply that has already gone to the customer cannot be removed, because it has already left the building.

Help-centre authoring sits entirely at the editor level, including creating, editing, publishing and deleting articles and collections, and managing preview links and the custom domain. The two exceptions are exporting the whole help centre and changing branding or the widget, both of which are admin.

Anything that carries a credential or points at another system is admin: channels, integrations, webhooks, API keys and automation settings.

Two details worth knowing

Removing a member does more than remove them from the list. When an admin removes somebody from the workspace, their team memberships are deleted and their sessions and API keys are revoked at the same time. Removal takes effect immediately rather than at their next sign-in.

API keys borrow the role of the person who created them. A key has no role of its own; it acts with whatever role its creating member currently holds. If that member is demoted, every key they minted becomes less powerful at the same moment, and if they are removed from the workspace their keys stop working. Keys can be narrowed by scopes, but a scope can only restrict what a key may do — it can never grant more than the underlying member's role allows.