Managing access

Access is managed in the Admin → Access area. The screen is split into three tabs that together cover the whole path: first we describe what is possible (roles), then to whom and where (assignments), and for pinpoint exceptions — separate grants.

0:000:00

An administrator issues a point access grant — effective immediately

Tab	About	Main object
Roles	tenant permission sets	Role
Assignments	who received a role and in which scope	RoleAssignment
Grants	pinpoint permissions for a single principal	PermissionGrant

Principal

A “principal” is any account that can be granted access: a person, a module, or a system identity. The Admin → Users area shows all the tenant’s principals; access is granted precisely to them.

Access requests

Access is always granted by an administrator — there is no self-service automated request queue yet. When a user lacks permission for a screen, they see the “Insufficient permissions” state showing which permission and which scope is required, plus a “Copy access request” button. The button copies a ready-made, structured request to the clipboard (who, which permission, which scope, and a request id) — the user hands it to an access administrator by whatever means your organization uses.

Once you receive the request, you grant the permission here — with a role assignment (the “Assignments” tab) or a pinpoint grant (the “Grants” tab) at the required scope. The new access takes effect immediately: worklists and queues are built from permissions, not from cached roles.

Grant no more than needed

The request names a specific permission and scope — grant exactly those. A permission propagates down the hierarchy, so an assignment at the study level gives access to all its sites and subjects; if a person needs one site, assign it on that site, not on the study.

The “Roles” tab

A role is tenant data: a template is copied and then freely edited. Here you can see how many permissions and active assignments a role has.

Create a role from a template

1. On the “Roles” tab, click “Create from template.”

2. Choose a template (Study Builder, CRC, Investigator, CRA, Data Manager, Medical Monitor, Medical Coder, Inspector, Tenant Admin). You can leave the name empty — then the template’s name is used.

3. The role is created with the template’s set of permissions. Open its page to fine-tune the permission set: they are grouped by object, with module permissions under their own module.

4. Save your changes.

Editing a role affects everyone it is assigned to

Changing a role’s permission set immediately changes the effective access of all its assignments. That is why, when saving, the system shows how many active assignments will be affected and asks for confirmation. Only a role that was never assigned can be deleted; history is not erased.

The “Assignments” tab

An assignment links principal × role × scope × term. This is precisely where a role turns into real access.

1. Click “New assignment,” choose a principal and a role.

2. Set the scope — along the hierarchy, without skipping segments. You cannot grant access “to a subject” while skipping the site: the path is built in order, study → site → subject. A handy scope builder helps assemble the path, or it can be entered manually.

3. If needed, set a term (“Valid until”). Empty means indefinite. All timestamps are stored in UTC.

4. Click “Assign.” The action is recorded in the audit trail (the core.access.granted event).

Scope determines where access applies

A permission propagates down the hierarchy from the point of assignment: a role at the study level covers all its sites and subjects; a role on a specific site — only that site. This is the same mental model as breadcrumbs and page addresses.

The “Grants” tab

Grants are pinpoint permissions for a single principal, in addition to roles. They are used for exceptions: give one person one permission (grant) or, conversely, deny one pinpoint permission (deny). Select a principal to see and change their grants.

• grant — allow. Give a specific permission in a specific scope.
• deny — forbid. A pinpoint denial that always wins over any grant on the path — “a surgical exception that no role can override.”

Deny grants and delegation are covered in detail in SoD and delegation.

Restricting entry into a specific form

A common SOP: laboratory results are entered only by a lab data enterer, drug accountability only by an unblinded pharmacist, while everyone else sees those forms read-only. In X7 Insight this is a design × access pairing:

1. The designer tags the form with an entry-restriction tag (a form property in the builder, e.g. lab). The tag is part of the design: versioned and shown in amendment diffs.

2. The platform automatically adds the permission “Enter forms tagged ‘lab’” (form.entry.lab) to the catalog.

3. The administrator builds the dedicated enterer’s role — e.g. “Lab Data Entry”: the usual entry permissions (data.enter, data.update, …) plus form.entry.lab — and assigns it to the right people at the right scope.

Writing into the tagged form now requires both permissions: a coordinator without form.entry.lab gets the form read-only with an explanatory banner (queries, SDV and review keep working), while the lab enterer fills it in normally. If the tag is set but nobody holds the permission, the design validator warns that nobody will be able to fill the form in.

Revoking access and the cascade

Both a role assignment and an individual grant can be revoked with the “Revoke” button. Revoking does not delete the record: the assignment is closed (its term is set to “now”), and history is preserved.

Cascading revocation

If the revoked grant had permissions delegated from it (someone received access on the basis of this grant), they are revoked in a cascade — the system warns about this and shows how many delegated permissions are closed together with the base one. This rules out “dangling” access with no basis.

Why a person does or does not have access

If access behaves unexpectedly (“I see less than I should” or “why does this person have access to X”), do not guess — use the “Check access” tool on the principal’s card (Admin → Users).

1. Open the principal’s card and choose “Check access.”

2. Specify the scope you want to check.

3. For each applicable permission, the system shows the outcome — “allowed” or “denied” — and the source of the decision: from which role (role "…" @ scope) or from which grant (grant grant/deny @ scope).

The tool reproduces the same logic as the entire access engine: all applicable grants are collected by path prefixes, with any deny winning; when there are no applicable grants, default deny applies. If the principal is deactivated, everything is denied, regardless of sources.

You cannot grant more than you have yourself

An administrator acts only within the scope where they themselves have the access.grant permission. You cannot grant yourself or another person access broader than your own — an attempt is rejected and recorded in the audit. This is protection against self-escalation.