Access in Trialion is decided by permissions. A role is a named set of permissions, and a person is given a role on the organization, on a study or at a site. This page lists the 15 standard roles and the 68 permissions they are made from, exactly as the system holds them. The rules that sit on top of the roles (who may not hold two seats, who may not act on their own work) are on Who can and cannot; what each role does day to day is under Roles.
Roles & Permissions in the main menu (an Organization Admin; the permission is rbac.manage) lists the standard roles and the organization's own, and is where a custom role is drawn up. A person's own permissions are shown by what the screens offer them. The interactive explorer below lights up what a role holds, or who holds a permission.
Click a role (column) to see everything it can do, or a permission (row) to see who holds it. Access is further narrowed by study membership, site scope, and environment (ABAC).
Read the standard roles and permissions (this page, or the Roles & Permissions screen).
Create a custom role from a standard role as its starting point, adding or removing permissions within the rules below (Manage organization roles). A role has the level of the role it starts from, and the setup wizard creates a set of up to 40 roles together, all of it or none of it.
Suspend and restore a custom role, and change it; each change is kept as a revision with the reason.
Ask the role assistant for suggestions of permissions that fit a role and for an explanation of a warning. It decides nothing: what it proposes is checked like anything typed (Not built yet says what the AI does and does not do).
A standard role is a template in the code, with a version that changes whenever its permissions do. It cannot be changed or suspended by anyone; a custom role starts from one. The number is how many of the 68 permissions the role holds.
Role
Identifier
Short
Held at
Permissions
What it is for
Organization Admin
org_admin
OA
The organization
48
Governs org users, the role catalog, and studies with read-only clinical oversight.
Project Manager
project_manager
PM
One study
42
Runs study execution — staffs the team, creates sites, tracks quality; can raise queries.
eCRF Designer
ecrf_designer
ED
One study
12
Builds forms, libraries, mappings. No clinical data access.
Clinical Research Associate
cra
CRA
One study
16
Monitors site data quality (SDV), views data, raises queries (cannot edit or answer).
Held through a role at one site. Data entry is held here and nowhere else
A permission held at the wrong level does not count: a role cannot carry a permission its level does not allow, and a grant of the wrong level confers none of it.
27 of the 68 permissions are above standard risk (elevated or critical). They are governance permissions: every decision to allow them is written to the audit trail, and a person who does not hold one cannot pass it on to someone else. The custom-role editor warns when a role holds them.
Role short names: OA Organization Admin · PM Project Manager · ED eCRF Designer · CRA Clinical Research Associate · DM Data Manager · MO Medical Officer · SM Sponsor Manager · SSM Sponsor Supply Manager · AUD Auditor · PI Principal Investigator · CRC Clinical Research Coordinator · PH Pharmacy · STM Site Monitor · CDC Clinical Data Coordinator · RM Regulatory Manager.
Creating, changing, suspending and restoring a custom role, accepting a warning with a reason, and asking the role assistant are in the organization's audit trail (rbac.custom_role.created, rbac.custom_role.updated with the earlier version kept as a revision, rbac.custom_role.suspended, rbac.custom_role.restored, rbac.custom_role.warning_overridden, rbac.ai.suggestion_requested). Every allow decision on a governance permission is recorded (authz.decision). See Audit events.
Yes. Every operation of the API declares the permissions it needs, and a request is refused before it reaches any data if the person's role at that level does not hold one. The permissions are fixed by the platform; roles are composed from them; and the table above is generated from the code, so it is what is enforced. Limits: whether the right people hold the right roles is your organization's decision and review (Review organization access and audit).
Evidence:server/src/modules/platform/rbac/domain (permission.ts, role-catalog.ts) · server/src/api/middleware/authorize.ts · this page is generated from them
Compliance Q&ABuiltPart 11 11.10(g)Annex 11 12
Can a role be given both sides of a separation of duties, such as entering data and locking it?
No. Permissions on opposite sides of a pair are marked in the catalogue, and a role holding both is refused with a hard error that no administrator can accept.
Evidence:server/src/modules/platform/rbac/domain/sod.ts · server role guardrails (hard error in the role editor, whoever is editing)