Permission catalog

Access in X7 Insight is built from atomic permissions of the form “object.action” (for example, data.update). Roles are simply named sets of such permissions, issued to a principal within a particular scope. Below is a catalog of what can be permitted at all, grouped by work area, and the principles by which the system makes its decision.

Permission = visibility

You see on screen only the buttons and sections you have a permission for in the current context. If an action isn’t there, it isn’t available to you here. This is a UX hint; the real protection is provided by the server, which checks the permission for every action.

Study design and build

Permission	What it allows
study.create / study.read / study.configure	create, view, and configure a study
study.lifecycle.change	move a study through its statuses (draft → UAT → active → …)
studyversion.create / studyversion.update	create and edit a design version (edits only in a draft)
studyversion.submit_review / .approve / .publish / .retire	move a version through its cycle: submit for review, approve, publish, retire; return a version from review to draft (same submit_review or approve)
mdr.read	read study metadata (forms, code lists, edit checks)
designcomment.read / designcomment.write	view and leave/resolve design-review comments (ADR‑054; read comes with mdr.read)
translation.manage / translation.approve	manage and approve translations
site.activate / site.deactivate	activate a site on a published design; close and reopen it
designtemplate.read / designtemplate.manage	view and manage the tenant’s design template library

Approval: separation of duties (ADR‑074)

Approving a design version (and a translation bundle) goes through separation of duties. The default mode is soft: an author may approve their own object, but that act is always marked in the audit as self_approved. The strict mode (the core.sod.strict_approvals setting, per tenant or per study) requires the approver not to be the author. The only exception is the personal waiver studyversion.self_approve / translation.self_approve (the *.self_approve family): a documented relaxation for organizations without a second pair of hands (ADR‑042). A module cannot hold this waiver.

Subjects and data

Permission	What it allows
subject.create / subject.read	enroll and view subjects
subject.status.change	change a subject’s status (enrollment, withdrawal, etc.)
subject.status.correct	correct a mistakenly set status outside the state machine (with a reason)
subject.randomize	randomize a subject (number and blinded arm code)
subject.migrate_version	migrate subjects to a new design version
visit.create / visit.update	create visits (incl. unscheduled); date them or mark missed
form.instance.create / form.instance.read / form.mark_complete	create and view forms and mark them complete
data.read	read values
data.enter	initial entry of a value (no reason needed)
data.update	editing a saved value (a reason, RfC, is required)
data.mark_not_done	mark “not done” / “unavailable”
data.unblinded.read	view unblinded blinded values (reads are audited)
form.entry.<tag>	enter data into forms with an entry restriction

Form entry restriction (form.entry.*)

A designer can tag a form with an entry-restriction tag — e.g. lab on “Laboratory Results”. Writing into such a form then requires, on top of the usual data.enter/data.update, the form.entry.lab permission — put it into the dedicated enterer’s role (e.g. “Lab Data Entry”). Everyone else sees the form per their permissions but cannot fill it in. The permission appears in the catalog automatically when the tag is set in the design. See Managing access.

Why entry and editing are separate permissions

data.enter and data.update are deliberately separated. For example, an ePRO participant can enter their responses but not edit saved ones — corrections are made only by staff and always with a reason. See Data entry and blinding.

Monitoring and cleaning

Permission	What it allows
query.read / query.open / query.answer	view, open, and answer queries
query.close / query.reopen / query.cancel	close, reopen, and cancel queries
query.assign	assign queries to a handler (queue label)
data.sdv.verify / data.sdv.unverify	set and remove the source data verification (SDV) mark
data.review.medical	perform medical review of data
data.coding.write	set the medical coding status

Signatures, locks, export

Permission	What it allows
signature.apply / signature.read	apply an electronic signature and view signatures
lock.read	view locks and their history
lock.apply.soft / lock.apply.hard	apply a soft and a hard lock
lock.release.soft / lock.release.hard	release a soft lock / reopen a hard-locked DB
export.run / export.read	run exports and view their history

Administration and access

Permission	What it allows
access.grant	issue and revoke grants, assign roles
access.delegate	delegate your own permissions (depth 1, within your own permissions and time window)
access.read	view issued grants and roles (admin and inspector)
role.manage	create and edit custom roles
principal.manage	create and deactivate the tenant’s accounts
audit.read	read the audit trail
audit.verify	run hash-chain verification
settings.read / settings.write	read and change platform settings within a scope
platform.administer	exceptional installation-level operations

Modules

Permission	What it allows
module.register	register a module manifest (at the platform level)
module.enable / module.disable	enable and disable a module within a scope
module.configure	configure a module
mod.<module>.<object>.<action>	a module’s own permissions from its manifest

What a module can never do

Modules are forbidden from requesting access-administration permissions (access.*, role.manage, module.*, platform.administer), releasing locks (lock.release), signing on a person’s behalf (signature.apply), and running audit verification (audit.verify). A module does not administer access and does not sign in place of a person. See Modules.

Access principles

How exactly the system decides whether an action is allowed. Understanding these four principles explains almost any “why can’t I”:

• Default deny. No matching grant means no access. Nothing is allowed “by default.”
• Deny-wins. If there is even one denying grant (deny) on the resource’s path, there is no access — even when allowing grants exist. An explicit deny is stronger than any allow.
• Scope. A permission is granted on the path study → site → subject → form → field and applies to that path and everything beneath it. A permission on a site does not grant rights over the whole study; the hierarchy is itself the mechanism for breadth — there are no wildcard “asterisks” (*).
• Time-boxed. A grant may have a “from… to…” window. Outside the window it has no effect. Revocation and expiry take effect immediately; for example, an inspector’s access is issued with the inspection’s end date.

Separation of Duties (SoD)

Separate rules block (block) or warn (warn) against a dangerous combination of permissions in one person. The defaults: “whoever entered the data does not verify it against source” (block); “signer and SDV verifier” (warn); “access granter and data editor” (warn). The check is performed at the moment a grant is issued or a role is assigned. A combination under the warn policy is possible, but the fact is recorded in the audit.

Why can't I?

The model is explainable: the system can show the list of applicable grants for any decision — this is the basis of the “why” screen. If an action is unavailable, contact your tenant’s access administrator. See Roles & access.

Roles & accessHow roles are assembled from permissions and where your access comes from.

GlossaryPermission, grant, scope, role, SoD, principal — in plain language.

Status lifecycles and axesWhich permissions each transition requires.

Blinding and privacyHow data.unblinded.read controls the visibility of blinded values.