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” 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. Specialised 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)	everything a CRC does, plus electronic signature of data and opening queries	site
CRA	Monitor	source data verification (SDV), opening/closing queries, monitoring visits	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 axis), the coder inbox	study
Inspector	Inspector / auditor	read-only access: data, value history, audit trail, chain verification	study (time-boxed)
Tenant Admin	Administrator	users and roles, access and grants, settings, modules, version lifecycle and publishing	tenant

What each persona does

• Study Builder — works in the “Study design” section: assembles CRFs, code lists, validation rules, and the visit matrix, and takes the design through review and approval. Approving and publishing the design must be done by someone else — see separation of duties (SoD). See Study design.
• CRC (coordinator) — the main data entry: creates subjects, opens visits and forms, enters values, edits them with a stated reason (RfC), responds to queries at their site.
• Investigator (PI) — responsible for the site’s data: everything a CRC does, plus the electronic signature of forms and casebooks (a legally significant act with re-authentication), as well as opening queries.
• CRA (monitor) — verifies data against source documents (SDV), opens queries on discrepancies and closes them after the site responds, conducts monitoring visits. Usually works across a pool of sites.
• Data Manager (data manager) — data quality at the study level: bulk work with queries, monitoring SDV progress, locking the database (soft → hard lock), launching exports, and assembling the closeout package.
• Medical Monitor (medical monitor) — the sponsor’s physician: reviews safety and efficacy data, marks the medical review, raises medical queries, without mixing into data cleaning.
• Inspector (inspector) — read-only access with a time limit: sees data, value history, the audit trail, and can independently verify the integrity of the chain. Cannot change, export, or unblind anything. See Inspector access.
• Tenant Admin (administrator) — administers the tenant: users and roles, granting access and pinpoint grants, settings (including strict SoD on approvals), the lifecycle and publishing of design versions, and connecting and configuring modules (coding, export, RTSM, ePRO, etc.), deliberately approving the permissions they request.

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 “telling”: 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 right 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 right to sign “on their behalf.”

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

SoD and delegationSeparation of duties, covering, deny grants.