Roles & Permissions

Every member of an organization holds exactly one role. That role determines what they can do inside the workspace.

The role model is intentionally small. There are a handful of pre-defined roles that fit most organizations, and the option to define custom roles for environments that need finer-grained control.

The default roles

Three roles ship with every organization:

Role	What they can do
Admin	Everything. Invite and deactivate members, change roles, edit organization settings, manage classifications and forms, review audit log, configure public-access surfaces.
Auditor	Read-only across the workspace. Can view organization, members, audit log, and most settings, but cannot change anything. Useful for compliance reviewers and security teams.
Member	Day-to-day workspace use. Can see the organization, see other members, and use the product. Cannot administer anything.

If you’re not sure which role to give someone, Member is almost always the right starting point. Promote them later if they need more.

How permissions are grouped

Each role is a bundle of permissions. Permissions cover specific kinds of action and are grouped into categories:

Category	Examples of what’s gated
Organization	View org settings, edit org settings.
Users	View members list, invite members, deactivate members.
Audit	View the audit log.
Forms	View form templates, create and publish them.
Classification	View sensitivity levels, define new ones.
Public sessions	View public-session templates, create and manage them.

Inside the product, when an action is gated by a permission your role doesn’t have, the relevant button or page is hidden — you won’t see it at all, rather than seeing a “permission denied” error.

What the default roles include

A simplified view of the matrix:

	Admin	Auditor	Member
View organization	yes	yes	yes
Edit organization	yes	no	no
View members	yes	yes	yes
Invite / deactivate members	yes	no	no
View audit log	yes	yes	no
Manage classifications	yes	no	no
Manage forms	yes	no	no
Manage public sessions	yes	no	no

Member is read-mostly on administration: members can see the workspace, see who else is in it, and use whatever the product surfaces to them, but they cannot change the configuration.

Changing a member’s role

From Settings → Users, find the member, click their row, and pick a new role. The change takes effect immediately on the next page load (or instantly if they trigger any action that re-checks permissions).

Role changes are recorded in the audit log with the actor, the affected member, the old role, the new role, and the reason you provided.

Be deliberate about admin role grants. An admin can deactivate other admins, change anyone’s role, and read everything. The system does not require a second-admin confirmation for sensitive role changes. Treat admin assignment with the same seriousness as you treat sharing root credentials.

Custom roles (Sovereign)

Sovereign organizations can extend the role list with custom roles. The system roles (Admin, Auditor, Member) are always present and cannot be edited; custom roles sit alongside them.

A custom role is a name plus a chosen subset of permissions. Use them for cases like:

Read-only forms reviewer — Member permissions plus form-template view.
Security investigator — Auditor permissions plus public-session view.
Support engineer — Member permissions plus permission to read but not write classifications.

Custom role creation lives in Settings → Roles (admin permission required).

Cloud workspaces on the standard tiers use the default roles only. Custom roles are an enterprise-tier capability there; talk to your account team if you need them.

The “right to do” vs the “right to see”

A few things to know about how permissions interact:

Permissions are positive. You either have a permission or you don’t. There’s no “deny” rule layered on top.
Membership in the organization is a precondition. Permissions only apply inside organizations you belong to. They don’t give you cross-org access.
Some actions check additional context. For example, deactivating yourself is not allowed, even if you’re an admin. Demoting the only remaining admin is not allowed. These rules sit on top of role permissions for safety.
Install admins are not members. In Sovereign, install admins manage the infrastructure but do not get any organization permissions automatically. They must be explicitly invited to an organization to act inside it.

Auditing role changes

Every change to a role assignment is recorded. Filter the audit log on user-management events to see who changed whose role and when. Combined with the reason field captured at the time of the change, this is your trail for compliance reviews.

Members & Invitations — assign a role when inviting.
Audit Log — every role change is recorded there.