Manage organization roles

What this is, and who it is for#

A role is a named bundle of permissions. The 15 standard roles ship with the product, are locked and are checked for separation of duties; an organization may add custom roles of its own. Roles & Permissions is where they are read, created, cloned, edited and suspended. A role is given to a person elsewhere: an organization-wide role when they are invited (Invite and manage members), a study role on a study's team (Staff a study team) and a site role on a site's staff (Staff a site).

Held by: Organization Admin (rbac.manage).

The Roles screen's own gate is rbac.manage; nobody else sees it in the menu. What every standard role holds is on Roles and permissions; this page is how to work with them.

Where to find it#

Administration → Roles & Permissions (The role catalog. Standard roles ship locked and SoD-safe; clone one or build a custom role to fit your organization.). Three tiles show Total roles, Standard (Built-in · locked catalog) and Custom (Created by your org). Two tabs: Roles and Permissions.

What you can do#

Read the catalog#

The Roles tab lists every role: its name and description, Short form, Type (Standard or Custom), Scope, Holders (people who hold it), Perms (how many permissions), and Status (Active or Suspended). Filter by type and scope (All types, Standard, Custom; All scopes, Platform, Study, Site) or search (Search roles by name, abbr…). The screen calls the organization-wide scope Platform; the setup wizard and the access report call it Organization. The Holders figure is "—" when it cannot be read, so a failed read is never shown as nobody.

Open a role (click it, or View details) to see a side panel with its scope, type and status, the number of holders, permissions and modules, Permissions by module (with Show denied to see the ones it lacks, crossed out), its History (custom roles) and its Holders: the first 25 people with the grant, where, in which workspace and whether it confers access today, with See all {n} in the access report.

The Permissions tab lists the whole permission vocabulary by module and, for each permission, the roles that grant it (a chip for each, in the color of its scope; click one to open the role). It answers "who can apply an investigator e-signature?".

1

2

Enlarge

1. Opens the dialog that creates a custom role.
2. Finds a role by name.

Enlarge

Create a role#

New role opens New role (Roles bundle permissions. Members get the union of their roles' permissions.). Fill in:

• Role name (required; unique across the standard roles and yours, case-insensitive: A role with this name already exists.).
• Scope (required): Platform (organization-wide), Study or Site. Fixed once the role exists.
• Description (What this role does and who should have it.).
• Permissions (required): grouped by module, with a search and a tick for a whole module. The count of selected permissions is shown.
• Investigator role (a site role only): Only an investigator role can hold eligibility, signing and delegation permissions. This cannot be changed after the role is created.
• Reason for creating this role (required, at least 3 characters): Kept with the role's history — who changed what, and why.

The panel judges the role as you work and blocks Create role while a rule is broken: Investigator-only permissions — fix before saving, Segregation-of-duties conflict — fix before saving, a permission the scope cannot hold. When the server refuses (The server refused this role — nobody can override these), or raises a warning (Say why each of these is acceptable to save the role), the panel stays open with the form filled in; give a reason for each warning and save again.

Starting points. Start from a template offers six: Blank, Viewer, Site Coordinator, Data Manager, Study Manager and Administrator, each with a one-line pitch and the number of permissions it ticks. They are a convenience and nothing more: the role is judged exactly like any other.

Known problem. The Study Manager and Administrator starting points tick study.publish, a permission that no longer exists (it was retired by ADR 0013). It is not shown in the list, so it cannot be unticked, and the server refuses the role as it stands (These are not permissions the system defines.). Use another starting point, or cloning (below), until this is corrected. This was found by reading the code and is not covered by the simulation of 20 Oct 2026.

1

Enlarge

1. Start from a blank role or from a standard one, then name it, choose its scope and pick its permissions; the guardrails check the result.

Clone a role#

Clone to customize (a standard role) or Clone (a custom one) opens Clone role pre-filled as Copy of {name}. The copy is always a new custom role you can edit freely; the original is untouched. A copy of a standard role starts from that role's template. This is the only way to base a role on the locked catalog.

Edit a custom role#

Edit (custom roles only; a standard role cannot be edited or removed) changes the name, description and permissions. The scope cannot change (clone it to create a new role at a different scope), nor whether it is an investigator role. A reason for this change is required. Changes apply to everyone who holds the role on their next request, and every save is a new revision: nothing is overwritten. If someone else changed the role after you opened it, the panel says Someone else changed this role after you opened it and you open it again to work from the latest revision.

The role's History lists every revision newest first: the number, when, who, the reason in quotation marks, Created · {n} permissions for the first, From {role} v{n} when it started from a template, Renamed from …, the permissions added (+) and removed (−), No permission changed when only the text did, and any Accepted a warning on {permission}: "{reason}".

Enlarge

Suspend and restore a custom role#

Suspend (Suspend "{name}"?) retires the role. The screen says it is retired from new assignments; in fact a suspended role holds nothing: the server resolves a role that is not active to no permissions, so everyone who holds it loses what it granted from their next request, until it is restored. The definition and its history are kept, roles are never deleted, and Restore brings it back. Standard roles cannot be suspended.

Enlarge

1

Enlarge

1. The dialog says nothing about people who already hold the role: they lose what it grants.

Every option#

The guardrails#

The server judges every create and every edit with the same rules, and the panel shows the ones it can see for itself. There are two kinds.

Hard errors have no override, not even for the Organization Admin:

Warnings need a reason you can stand behind (at least 3 characters), recorded with the revision. They are judged on what an edit adds, so a risk accepted once is not asked again on every later edit:

The risk rating of every permission is in Roles and permissions.

Rules about names#

A name is unique across standard and custom roles. A role made from a standard role's template may keep that role's own name; it then replaces its standard twin in every picker, so nobody sees two of the same. A custom role, like a standard one, can be given on a study that is still in Setup: the old rule that refused every role but the build team's before UAT was retired (ADR 0013), and the simulation staffed a Setup study with Clinical Research Associate, Medical Officer and site roles.

What the system records#

rbac.custom_role.created, rbac.custom_role.updated (the earlier version is kept as a revision with its reason), rbac.custom_role.warning_overridden (for each accepted warning, with its reason), rbac.custom_role.suspended and rbac.custom_role.restored. See Audit events.

What you cannot do, and why#

• Edit, suspend or delete a standard role. They are the validated catalog; a variant is a clone.
• Delete any role. Roles are suspended and kept, so the record of who could do what stays intact.
• Change a role's scope or investigator flag after it exists.
• Save a role with a separation-of-duties conflict or a permission its scope cannot hold, whatever the reason given.
• Give yourself more. An administrator cannot add permissions to a role they hold, and nobody gives themselves an access exception (Review organization access and audit).
• Give an Organization Admin a study role. An Organization Admin holds no study role; the rule is enforced in the server and in the database.

Compliance Q&A#

Related#

Roles and permissions · Set up your organization · Invite and manage members · Review organization access and audit · Organization Admin