Roles as data

In X7 Insight, a role is data, not code. No check in the system asks “are you a CRC?”. Instead, each role is a named set of atomic permissions (for example, “read data,” “edit data,” “verify SDV”), and actual access is always computed from the permissions granted to you in a specific scope (study → site → subject → form).

0:000:00

The Access screen: roles, assignments and grants — how roles become permissions

Why this matters for you

Different sponsors and different studies have different regulations (SOPs). Because roles are configured as data, one and the same product serves incompatible processes without rewriting code. The practical takeaway: the “CRC role” in your study is exactly the set of permissions your administrator configured, not a universal constant.

Persona templates

The platform ships role templates — ready-made sets of permissions. A minimal set of understandable roles is created automatically, as presets — “Study designer”, “Site coordinator”, “Investigator”, “Monitor”, “Data manager”, “Auditor (read-only)” and “Administrator” exist in the tenant from day one (the installation bootstrap creates them; on an upgraded installation — “Reconcile with templates” in the roles section). Presets are fully editable: the name, description and permission set are yours; the template origin is preserved in the audit trail, and template updates shipped with platform upgrades reach even renamed roles. Specialized personas (medical monitor, coder, inspector) are created on demand — under “Admin → Access → Roles” or right from the “Add to team” wizard on the study team page, with a human-readable title and description.

Template	Persona	What it does	Typical scope
Study Builder	Design builder	assembles forms, code lists, edit checks, the visit schedule; submits the design for review	study
CRC	Site coordinator	enrolls subjects, enters and edits data, responds to queries, records visit dates	site
Investigator	Investigator (PI)	views site data, signs completed forms, the site’s audit trail, their own copy export	site
CRA	Monitor	SDV, opening/closing queries, export of the SDV report and the query register	pool of sites
Data Manager	Data manager	data cleaning, bulk query operations, database lock, exports	study
Medical Monitor	Medical monitor	medical review of safety data, medical queries	study
Medical Coder	Coder	medical coding of terms (the coding status), the coder inbox	study
Inspector	Inspector / auditor	read-only: data, SDV, signatures, locks, the audit trail, chain verification; no file exports	study (time-boxed)
Unblinded Statistician	Unblinded statistician	uploads and retires the randomization list, sees arm codes by role (each access is logged); enters no data	study
Tenant Admin	Administrator	users and roles, access and grants, settings, modules, version lifecycle and publishing	tenant

What each persona does

The table above answers the question “what is allowed.” This section is about what each persona is actually busy with and responsible for.

• Study Builder — runs the “Study design” section and takes the design through review. Approving and publishing must be done by someone else — see separation of duties (SoD) and Study design.
• CRC (coordinator) — the primary data-entry workspace: day-to-day work with the subjects, visits and forms of their site, including edits with a stated reason (RfC).
• Investigator (PI) — responsible for the site’s data as a whole: signs what is completed (a personal act with re-authentication) and opens queries. Responsible means seeing: the audit trail of their own data, the list of those with access to their site, and an export of their own copy of the data are available to them without an intermediary (ICH E6(R3) §3.16.1, EMA §6.2.2 and §6.6).
• CRA (monitor) — conducts monitoring visits and works across a pool of sites.
• Data Manager (data manager) — holds data quality at the level of the study as a whole: from bulk cleaning to locking the database and assembling the closeout package.
• Medical Monitor (medical monitor) — the sponsor’s physician: reads safety and efficacy data and raises medical queries, without mixing into data cleaning.
• Inspector (inspector) — the eyes of the regulator or an auditor: independently verifies the integrity of the audit chain. Building documents (file exports) is unavailable to them in principle — there is no export.run permission, nor the permission to unblind. See Inspector access.
• Tenant Admin (administrator) — administers the tenant as a whole: from users, roles and settings (including strict SoD on approvals) to the lifecycle of design versions and enabling modules.

Tip

There are also other personas that arise when modules are connected: Coder (MedDRA/WHODrug coder), Unblinded Pharmacist (unblinded RTSM pharmacist), Subject (a participant for eConsent/ePRO). Their permissions appear together with the corresponding module.

Permissions are grouped by object

When you open a role for editing, its permissions are grouped by the object they relate to: access, study and design, subjects and data, work objects (queries, signatures, locks, export), while module permissions (mod.*) sit under their own module. Permission names are self-explanatory: data.read (read data), data.update (edit), query.answer (answer a query), signature.apply (sign). The full catalog is in the permissions reference.

A role ≠ a signature

A role grants permissions, but a personal electronic signature is not delegated. The permission to sign (signature.apply) can be granted, but the signature itself is always applied by a specific person with re-authentication. Covering for a colleague during vacation transfers permissions, but not the permission to sign “on their behalf.”

What’s next

Managing accessThe Admin → Access screen: roles, assignments, grants.

SoD and delegationSeparation of duties, covering, deny grants.