Manage team access

Access is made of two things: what may be done (a role — a set of permissions) and to whom and where (assigning the role to a person on a study, a site or the whole organization). This page covers granting, narrowing, revoking and checking access.

Who and when

Administrator — the access administrator. Permissions:

• assign and revoke roles, grant and revoke single permissions — access.grant;
• create and edit roles — role.manage;
• create and deactivate accounts — principal.manage;
• view granted permissions and roles — access.read.

The task comes up when a new person joins the team, when someone sends an access request (“No access”), when duties change and when a person leaves the study.

Before you start

• You yourself hold the right to grant access where you are about to grant it: you cannot grant access wider than your own.
• Decide where the person needs access. A permission propagates down the hierarchy: an assignment on the study gives access to all its sites and subjects. If one site is enough, assign on that site.
• The role you need already exists in Roles — or create it from a template (below).

Steps

1. Open Admin → Users and the person’s card. A new person? Click Invite user — the invitation offers a role right away; if you skipped it, Assign a role now in the invitation result opens their card.

2. Click Assign role.

3. Choose the role and where it applies: the whole organization, a study or one of its sites. The path follows study → site → subject without gaps.

4. Optionally set an end — Valid until. Empty means no end. All timestamps are stored in UTC.

5. Click Assign. You see “Role assigned”.

0:000:00

An administrator grants a permission — effective immediately

Answer an access request

When a person lacks permission, instead of the screen they see No access with one sentence naming the permission and the place, for example: “You need the ‘Read audit trail’ permission in ‘X7-DEMO-001’. Your access administrator grants it.” The Copy request for the administrator button copies a ready request (who, which permission, where, request id); technical details sit under Details for the administrator. Once you receive such a request, open the person’s card and assign a role or grant the permission exactly where it is needed.

Create a role from a template

1. In Admin → Roles, click Create from template.

2. Pick a template (study builder, site coordinator, investigator, monitor, data manager, medical monitor, medical coder, inspector, administrator). The name may be left empty — the template name is used then.

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

4. Save the changes.

Editing a role affects everyone who holds it

Changing a role’s permission set immediately changes the access of all its holders. On save the system shows how many active assignments are affected and asks for confirmation. Only a role that was never assigned can be deleted; history is never erased.

Allow or deny a single permission

For exceptions, a person can be given a single permission directly: the Grant permission button on their card.

• Allow — a specific permission in a specific place.
• Deny — a pinpoint prohibition that always wins over any allow on the path: an exception no role can override.

Restrict entry to a single form

1. The designer marks the form with an entry restriction tag (a form property in the builder, e.g. lab).

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

3. Build the dedicated clerk role — e.g. “Lab data entry”: the usual entry permissions plus form.entry.lab — and assign it to the right people in the right place.

Revoke access

On the person’s card click Revoke next to a role assignment or a single permission (a role’s holders can also be revoked on the role page) and confirm. The assignment closes as of now.

Check why a person does or does not have access

1. Open the person’s card in Users, section Check access.

2. Choose where to check — the organization, a study or a site — and click Check.

3. For every applicable permission the system shows the verdict allowed or denied and the source of the decision: which role (‘role “…” in “…”’) or which direct permission (‘direct permission in “…”’, ‘deny in “…”’).

What happens

• New access takes effect immediately: worklists and queues are built from permissions, not from cached roles. Revocation and expiry take effect at once too.
• Every assignment, grant, deny and revocation is recorded in the audit trail.
• Revocation does not delete the record: the assignment closes, history is preserved.
• If someone received delegated access on the basis of the permission being revoked, it is revoked with it — the system warns and shows how many delegated permissions were closed. Dangling access without a basis never remains.
• The access check changes nothing — it only explains the decision.

If it doesn’t work

• No Assign role, Grant permission or Revoke buttons — you do not hold access.grant in that area.
• You cannot create or edit a role — you do not hold role.manage.
• The assignment or grant is rejected — you are trying to grant access wider than your own. The attempt is rejected and recorded in the audit trail (self-escalation protection).
• A segregation-of-duties (SoD) warning — a dangerous combination of permissions for one person: a block rule prevents the assignment, a warn rule allows it but the fact is audited. See SoD and delegation.
• The person still does not see what they need — run Check access: a deny may sit on the path, the assignment may have expired, or the account may be deactivated.
• The design validator warns “nobody will be able to fill this form” — the form has an entry restriction tag and nobody holds form.entry.<tag>.

Next

Give an inspector accessUrgent view-only access for the inspection period.

Permission catalogAll permissions and access principles: default deny, deny-wins, scope, validity.

Roles as dataHow roles are built from permissions and where access comes from.

SoD, delegation, and deny grantsDenies, delegation and segregation-of-duties rules.

More detail

Where access is managed

Where	What is there
Admin → Roles	the organization’s role catalog; a role’s page shows its permissions and holders
Admin → Users	a person’s card: their roles, direct permissions and the access check

A person is managed only from their card — there is no other place for it. A study’s team is convenient to review and extend on the study’s Team page.

Access is granted to an account. Usually it is a person, but a module has an account too (its permissions are confirmed when the module is enabled). Users lists every account of the organization.

Roles are organization data

A role is organization data: a template is copied and then freely edited. The catalog shows how many permissions and active assignments each role has. An assignment links person × role × place × period — this is where a role becomes real access.

Form entry restriction

A common rule: lab results are entered only by the lab data clerk, drug accountability only by the unblinded pharmacist, while everyone else sees those forms read-only. The entry restriction tag is part of the design: it is versioned and appears in the amendment diff. Writing to a tagged form requires both permissions: for a coordinator without form.entry.lab the form opens read-only with an explanatory banner (queries, SDV and review keep working), while the lab clerk fills it in normally.

How the system decides

The access check reproduces the same logic as the whole access engine: all applicable permissions are collected top-down along the path, any deny wins, and with no applicable permission the default is deny. If the account is deactivated, all access is closed whatever permissions it holds. An administrator acts only where they themselves hold the permission to grant access.

Cascading revocation

If someone received delegated access on the basis of the permission being revoked, it is revoked with it. Denies and delegation are covered in SoD and delegation.