What this is, and who it is for
Trialion decides what a person may do from three things: the permissions their role holds, where they hold them (the organization, one study, one site) and what the study allows right now (its state, its workspace). On top of that sit a few rules about people that no role, no custom role and no administrator can switch off: who may not hold two seats, who may not act on their own work, who may not sign for someone else.
This page states those rules once, with where each is enforced and what you see when it refuses. It is the page to read before you design a custom role, staff a study, or answer an auditor's question about separation of duties. What each role can do is on its own page under Roles; every permission is on Roles and permissions; every screen and who sees it is on Screens.
How a request is checked
Every API operation declares its access, and a request meets the layers in this fixed order. The layer that stops it gives the refusal, so a person who is not allowed never learns the state of a study.
| Order | Layer | What it asks | The refusal |
|---|---|---|---|
| 1 | License | Is the feature licensed for this organization? (only features that are switched, such as exports and the AI form builder; see Feature switches) | 403 |
| 2 | Membership | Does the person hold a role on this study, and for site staff at this site? | 404, the same as a record that is not there |
| 3 | Permission | Does their role hold any one of the permissions the operation lists, on the grants this record is about? | 403 |
| 4 | Workspace | Is the record in the workspace (UAT or Live) the person's session has entered? | 403; a session that has entered no workspace and asks for something a workspace owns gets 409 workspace.required |
| 5 | Study state | Does the study's state allow this kind of write right now? | 422 |
Two things follow. A permission held at the wrong level does not count: a site-only permission held by a study role is not held. And the Organization Admin bypass (an administrator passing a permission check) does not exist for clinical and signing actions: those use the strict check, which has no bypass. The strict operations are marked in the API reference.
The rules about people
| Rule | What is refused | Enforced by | What you see |
|---|---|---|---|
| The Organization Admin holds no study role | Adding an Organization Admin to a study team in any role; making someone an Organization Admin while they hold a study role | the application and the database (P0013) | The Study Team row for the administrator is disabled; the API answers 422 team.separation_rule with the kind organisation_admin_on_team or team_member_organisation_admin |
| One role per person per study | A second role on a study, even in the other workspace: a person has one role on a study, the same in UAT and in Live | the application and a unique index | 409 when the role is already held here; 422 team.separation_rule (second_study_role) for a different one held in the other workspace |
| One site per study, one role at a site | A second site of the same study, or a second role at a site | the application and the database | 422 team.separation_rule (second_site_in_study); 409 for a second role at a site |
| One side of the organization | A study-team role (an organization member's, or sponsor staff's) and a site role held by one person, on any study | the application and the database | 422 team.separation_rule (study_and_site_member) |
| Organization members are never site staff | An organization member added to a site team, as site staff or as external sponsor staff; site staff or sponsor staff made organization members while they hold such a role | the application and the database | The Add members dialog refuses before anything is sent; the API answers 422 team.separation_rule |
| A person cannot raise their own grant | Granting yourself a role that carries a permission you do not hold. Granting a role to someone else has no such comparison: the Project Manager staffs the team without a breakpoint | the application | 403 authz.insufficient_permissions |
| A custom role cannot be given both sides of a separation of duties | One role that can both raise and answer queries, or both enter clinical data and lock it (enter-vs-lock: subject.write, form.write, form.write_dispensing against study.state.change, study.lock, form.freeze) | the role editor, always, whoever is editing | A hard error in the role editor naming the two permissions; nobody can override it |
| Investigator-only permissions stay with investigators | subject.eligibility, signature.sign and delegation.sign in a role that is not an investigator's | the role editor | A hard error naming the permissions |
| A permission must fit the level | A site-only permission in a study or organization role, an organization-only permission in a study role | the role editor | A hard error; rbac.manage, user.manage and the other organization permissions cannot be carried by any study or site role |
| You cannot add to your own role | Adding a permission to a role you hold yourself | the role editor | A hard error |
A role that breaks none of these can still be risky, so the role editor raises soft warnings (a permission beyond the template, an elevated or critical permission, an unusual combination). An administrator may accept a warning with a recorded reason; the acceptance is in the audit trail (rbac.custom_role.warning_overridden).
The rules about acts
| Rule | What is refused | Enforced by | What you see |
|---|---|---|---|
| Raiser is not answerer, answerer is not closer | Answering a query you raised; closing a query you answered. A reopen clears the closer | the application and a database trigger | 409 clinical.separation_of_duties; the Queries screen hides the control and says why. See Work with queries |
| The person who entered a value does not verify it | Source data verification by the person who entered the value | the application and the database | 409 clinical.separation_of_duties |
| Three different people sign off a version | One person in two capacities, or one capacity signed twice. The capacity comes from the role: Author is the Project Manager, QA the Data Manager, Approver the Sponsor Manager. Each signature is bound to the design the passed UAT cycle tested | the application and the database | version.signoff_refused; the designer and the Organization Admin have no Sign off control |
| Two people lock and unlock the database | The person who requested a lock or an unlock confirming it. Each signs with an e-signature | the application | The requester has no Review and confirm control. See Close and lock a study |
| Only the investigator signs a delegation | The Project Manager, the delegate or anyone off the site's team signing a delegation. A site staff member other than the investigator has no access until the investigator has signed | the application | There is no Sign control for others; team.delegation_signer |
| Only the investigator records eligibility | A coordinator confirming eligible or ineligible | the application | The Consent and eligibility screen has no Mark eligible control for the coordinator |
| Pharmacy writes dispensing forms only | A pharmacist saving a clinical form | the server | The form is read-only for Pharmacy with a notice; if a save is tried, 403 naming the dispensing forms |
| The study team reads and queries, the site writes | A study-team role (Medical Officer, CRA, Data Manager and so on) changing a site's data. Nine permissions are held at a site and nowhere else: form.write, form.write_dispensing, subject.write, visit.write, clinical.event.write, clinical.contact.write, clinical.consent.write, clinical.query.answer and signature.sign | the role editor and the guard | A form opened by the study team is read-only and offers no Submit and no Sign and lock |
| A change to a submitted or signed record needs a query and a reason | Changing a value of a submitted or signed record without a query raised by someone else on that value. A query you raised yourself authorizes nothing for you | the application and the database | The value stays read-only, with a notice, until such a query is on it; then a reason for change is asked |
| A signature seals what it signs | A signed record cannot be changed behind the signature's back. An authorized change is allowed, and it withdraws the signature: the record is unlocked and needs signing again, and the withdrawal is written to the audit trail | a database trigger, so no writer can leave a signed record with changed data | The save says Your change withdrew the signature: the record needs to be signed again |
The rules about the study's state
What a study accepts depends on its state. The columns are the kinds of write the guard checks.
| State | New participants | Clinical data | Queries, SDV, signatures, deviations | Safety reporting | Version work |
|---|---|---|---|---|---|
| Setup | no | no (no Live data yet) | no | no | yes |
| Active | yes | yes | yes | yes | yes |
| On hold | no | yes | yes | yes | yes |
| Closed to enrolment | no | yes | yes | yes | yes |
| Completed | no | only a correction made by answering a query | yes | yes | no |
| Locked | no | no | no | no | no |
| Archived | no | no | no | no | no |
A study moves Setup → Active by itself when version 1.0 goes Live; every other move is a person's act with a written reason, by someone who holds study.state.change (hold, resume, close to enrollment, complete), study.lock (lock and unlock, two people) or study.archive (archive). A locked study answers every write with The study database is locked; no changes are permitted, and an archived one with The study is archived and read-only. Details are on Change the state of a study.
The two workspaces keep test and production apart: UAT holds test data against a version being validated; Live holds production data. Nothing created in UAT can appear in a Live view. A person enters a workspace deliberately, in a dialog that says what they will find and in which role; site staff with only one kind of role land in it directly. The study level (the Overview, versions, documents, team, settings) belongs to no workspace.
Who can do what
The matrix is worked out from the role catalog by a script, so it cannot drift from it. A tick means the role holds the permission, at the level that fits it; the rules above can still refuse the act.
| Action | OA | PM | ED | CRA | DM | MO | SM | SSM | AUD | PI | CRC | PH | STM | CDC | RM |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Create a study (study.create) | ✔ | ||||||||||||||
Staff the study team and sites (team.assign) | ✔ | ✔ | |||||||||||||
Design forms and visits (form.design) | ✔ | ✔ | ✔ | ||||||||||||
Submit a version to UAT (study.version.submit_uat) | ✔ | ✔ | |||||||||||||
Pass or fail a UAT cycle (study.uat.close_cycle) | ✔ | ✔ | |||||||||||||
Sign off a version (study.version.signoff) | ✔ | ✔ | ✔ | ||||||||||||
Take a version Live (study.version.go_live) | ✔ | ✔ | |||||||||||||
Start an amendment (study.amendment.start) | ✔ | ✔ | |||||||||||||
Register a site (site.write) | ✔ | ✔ | |||||||||||||
Activate a site (site.activate) | ✔ | ✔ | |||||||||||||
Sign a delegation of authority (delegation.sign) | ✔ | ||||||||||||||
Screen and enroll a participant (subject.write) | ✔ | ✔ | |||||||||||||
Record eligibility (subject.eligibility) | ✔ | ||||||||||||||
Enter clinical form data (form.write) | ✔ | ✔ | |||||||||||||
Enter dispensing forms only (form.write_dispensing) | ✔ | ||||||||||||||
Sign and lock a record (signature.sign) | ✔ | ||||||||||||||
Raise a query (clinical.query.raise) | ✔ | ✔ | ✔ | ✔ | ✔ | ||||||||||
Answer a query (clinical.query.answer) | ✔ | ✔ | ✔ | ||||||||||||
Close a query (clinical.query.close) | ✔ | ✔ | ✔ | ||||||||||||
Reopen a query (clinical.query.reopen) | ✔ | ✔ | ✔ | ||||||||||||
Plan source data verification (sdv.configure) | ✔ | ✔ | ✔ | ||||||||||||
Verify against source (sdv.perform) | ✔ | ||||||||||||||
Record an adverse event (clinical.event.write) | ✔ | ✔ | |||||||||||||
Review a serious event medically (clinical.event.review) | ✔ | ||||||||||||||
Reconcile a serious event (clinical.event.reconcile) | ✔ | ✔ | |||||||||||||
Report a protocol deviation (deviation.report) | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |||||||||
Hold, close to enrollment or complete a study (study.state.change) | ✔ | ✔ | |||||||||||||
Lock or unlock the database (study.lock) | ✔ | ✔ | |||||||||||||
Archive a study (study.archive) | ✔ | ||||||||||||||
Run an export (export.run) | ✔ | ✔ | ✔ | ✔ | |||||||||||
Read the audit trail (audit.read) | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |||
Verify the audit chain (audit.verify) | ✔ | ✔ | |||||||||||||
Manage roles (rbac.manage) | ✔ | ||||||||||||||
Invite and manage members (user.manage) | ✔ |
Role abbreviations: 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.
What the system records
Every refusal that comes from a separation rule is answered with a stable code (see Error messages). A governance act is written to the audit trail with the person who did it and the reason: role changes (rbac.custom_role.*), assignments (team.*), memberships and suspensions (platform.user.*), access exceptions (access.exception_*) and sensitive access decisions (authz.decision). See Audit events.
Suspending a person or ending their membership revokes their live sessions in that organization, so it takes effect within one request.
What you cannot do, and why
- Give someone a special exception to a separation rule. An access exception adds or removes one permission on one grant for a limited time (at most 90 days, with a reason; an elevated or critical one waits for a second approver). It cannot lift a hard rule: the guardrails above are not permissions.
- Be an Organization Admin and work on a study. Governing the organization and acting on clinical data are kept apart on purpose.
- Use one person for two seats. One role per study, one site per study, one side of the organization.
- Rely on a setting. None of these rules has an off switch in the product or in the platform console.
Known limits. A person who holds site roles in two studies can enter either by its address: entering the second starts a new session on that study's role, and within a study they are confined to their one site. There is no switcher for site staff, so the second study is reached by its address or a link. A role's constraints are checked when a role is edited and when it is granted, not by a periodic review: reviewing who holds what is a customer procedure (see Review organization access and audit).
Compliance Q&A
No. A person holds one role on a study, the Organization Admin holds none, a role cannot carry both sides of the separation-of-duties groups (query raise against answer, data entry against lock), and the acts that must be done by a second person (answering and closing a query, signing off a version, confirming a lock) are checked against the signed-in user by the application and, for the main ones, by a database trigger. The second simulation run confirmed each with real roles.
Evidence: server/src/modules/platform/rbac/domain/sod.tsrole-assessment.tsserver/src/modules/study/team/application/role-conflict.tsADR 0019simulation PERMISSION_OBSERVED.md
No. The hard guardrails of the role editor are refused for everyone, an Organization Admin included, and the clinical and signing operations use the strict check that has no administrator bypass. What an administrator can accept is a soft warning about a role, with a recorded reason; that is a judgement, not a rule.
Evidence: server/src/api/middleware/authorize.ts (strict guards)role-assessment.ts (hard errors)ADR 0008
Yes for the organization: suspending a person or ending their membership revokes their live sessions in it, effective within one request, and the record of who did it is in the audit trail.
Limits: the software acts when someone suspends or removes the person; it does not know that a person has left the company. Prompt offboarding, and reviewing who still holds which role, are your procedures. A person on a study team keeps that role until it is ended on the study, so end it there too.
Evidence: server/src/modules/platform/users/application/commands/set-user-status.tsend-org-membership.ts
No. The people rules and the act rules are code, and the main ones are repeated in the database, so a direct connection or a different client cannot get round them. The platform console's feature switches license features (exports, the AI form builder); they do not touch these rules.
Evidence: server/src/modules/platform/rbac/domain/sod.tsserver/db/schema.sql (trigger trg_queries_separation and the team membership triggers)contract tests of the route declarations
Related
Roles and permissions · Screens · Staff a study team · Manage organization roles · Work with queries · Sign off a version and go live · Close and lock a study · API reference