EN
Русский English Français
Sign in Create account
Administration and security

Access management

Allow and deny functions to people and groups, role matrix, approval of new accounts, why someone sees what.

The Portal Owner decides who uses which function. Any function can be allowed or denied to a person or a group, made available only to the people you allowed, project roles can be redefined, and new accounts can wait for your approval. For anyone, the portal shows what they can use and why.

YouEDC access model The Portal Owner decides functions; capabilities in a project come from the role. Portal functions (for example, “Data file profiler”) 1 Switched on for the portal? ✗ off for all 2 Portal Portal Owner? ✓ all that is on 3 Personal rule decides at once 4 Group rules deny wins 5 Function access all / allowed Example: Anna is in the group “UAT testers”. “Validation kit” is only for allowed people → allowed by the group (step 4). Capabilities in a project (for example, “Export data” in REG-DIAB-01) 1 Role in project given by the project administrator 2 Role matrix built-in or changed 3 “Take away” personally or by group Example: a monitor in the group “External auditors” reads data, but export is taken away from this group (step 3), in every project. Every change of rules, groups and approvals goes to the portal audit trail. Who, when, before and after; the hash chain can be verified.
Two branches. Portal functions (top) are checked step by step from left to right; the first step that applies decides. Capabilities in a project (bottom) come from the role; a person or a group can only lose them.

Portal functions: five steps

  1. Is the function switched on for the portal? Switched off in Functions and limits means off for everyone.
  2. A Portal Owner can use everything that is on. Rules do not apply to Portal Owners.
  3. A personal rule, allow or deny, decides at once. It is the strongest rule: stronger than groups.
  4. Group rules. If any of the person's groups denies the function, it is denied, even when another group allows it.
  5. The function's access: “every user” (the default) or “only people the Portal Owner allowed”. The validation kit (UAT / PQ) is set like this.
Example. Pharma Co is evaluating the portal. Create the group “UAT testers”, add Anna and Igor and allow the group “Validation kit (UAT / PQ)”. Nobody else sees the kit. When Igor no longer needs it, give him a personal “deny”: the group stays as it is.

Tools of YouEDC Studio are available only when YouEDC Studio itself is. Deny “YouEDC Studio” to a person and all its tools disappear for them at once.

Capabilities in a project

What a person can do in a study or a DM project depends on the role the project administrator gave them on the Sites and team page: manager, data manager, investigator, monitor, sponsor. The Portal Owner can:

  • redefine the role matrix for the whole portal (Administration, Access, Role matrix): for example, stop the role “Sponsor / viewer” from seeing the team. A changed cell is highlighted; “built-in” brings the original back;
  • take a capability away from a person or a group in every project: for example, the group “External auditors” reads data but cannot export.

A person or a group cannot get a capability beyond their role: the role in the project and the delegation log the project administrator keeps must stay true (ICH E6(R3)). Sites and access to the randomisation are also set by the project administrator.

“Why can they see this?”

On a user's card press “What this person can use, and why”. Every function and every capability in each of their projects shows the result and every step of the decision, for example: “Switched on → no personal rule → allowed by the group UAT testers”. A quick check of one function is at the top of the Access page.

Approval of new accounts

Approval of new accounts Sign-up the person fills in the form and consents Waiting cannot sign in; Portal Owners get an e-mail Admin checks, approves and adds groups Active “account approved” e-mail, sign-in open Declined cannot sign in; recorded in audit Three modes in Administration, Settings: No approval: an account works right after sign-up (as before). Approve self sign-ups: people invited by a project administrator get in at once. Approve everybody: nobody signs in without a Portal Owner, invited people too.
A new account waits for a Portal Owner and cannot sign in. The Portal Owner approves it and adds groups in the same step, or declines it.
  • Choose the mode in Administration, Settings. Approval is off by default, as before.
  • Portal Owners get an e-mail about every new account; the administration overview shows how many are waiting.
  • A waiting person who signs in with the right password sees “waiting for approval”. With a wrong password they get the usual “wrong e-mail or password”, so the sign-in form never tells whether an account exists.

Everything is recorded

Changes of rules, groups, function access, the role matrix, approvals and declines go to the portal audit trail: who, when, before and after, with the comment if there is one. The audit trail cannot be changed; the hash chain can be verified in Portal audit.