Personnel

Personnel are the members of your team who work on a study — coordinators, monitors, investigators, data managers. This is where you decide who can open the study and what they can do once inside.

Find it under Personnel, which has two tabs: Personnel and Roles.

Personnel come from your team. The search finds members of your Trialflare team. If you also belong to other teams and can find users there, it includes their members too, labelled with their team's name. If someone is not in the list when you search, you can invite them by email if you have permission to, or ask a team administrator to invite them — see User management.

Someone added from another team is still managed by that team: your team administrators can change their permissions on this study, but can't disable their account or reset their two-factor authentication.

Adding someone to a study

Click Add personnel to the trial, then search by name or email address. Start typing at least three characters. People already on the study are marked as Added.

Searching your team needs the users.list team permission (or users.create) as well as being a trial administrator. Without it, or users.invite to invite people by email, the button is greyed out: ask a team administrator to grant one, or to add the person for you.

Adding someone grants them a minimal baseline — enough to open the study and nothing more. They will see the study in their list but very little inside it until you give them permissions. They are emailed to say you've added them, with a link to the study — unless they are still finishing setting up their account, or belong to another team (their invitation, or that team, is how they reach Trialflare).

Inviting someone by email

If you are a trial administrator and hold the users.invite team permission (or users.create), the Add personnel to the trial box also has an Invite someone by email section. Enter their email address, tick any of this study's roles to give them, and click Send invitation. If you search for an email address and nobody matches, it is filled in for you.

What happens next depends on who the address belongs to:

  • Someone already in your team is added to the study straight away, with the roles you chose, just as if you had found them in the search, and emailed to say so.
  • Someone new to Trialflare is emailed a link to set up their account, which lasts seven days. They join your team, and can open this study with the roles you chose as soon as they have signed in. They appear in the personnel table straight away, as Invite pending in your team's user list until they finish.
  • Someone with a Trialflare account in another team is emailed an invitation to join your team. They get access to this study only when they accept it. If, by then, you can no longer invite people or manage the study, they still join your team but are not added to the study, and are told to ask you to add them. If a role you chose has been deleted in the meantime, they are added without it and told to check their access with you.

An invitation from here gives access to this study and nothing else in your team: no team permissions, and no other studies. A new account also gets your team's default permissions, as every new account does (see Settings). Each new person counts towards your team's user limit.

users.invite does not let you search your team. If you hold it without users.list, you only see the invitation section. Someone already on the study (directly or through one of its roles) can't be invited again, and an account that has been disabled can't be invited at all.

Giving someone permissions

Click Manage on their row. The dialog has two halves.

Role assignments. Assign any of the roles you have defined. This is the quickest and most consistent way to set someone up.

Permissions. Grant individual permissions directly. These are organised by scope:

  • Trial — applies across the whole study.
  • Site — applies only to one site's participants, files and packs.
  • Group — applies only to one participant group.

Site and group scopes are what make delegated access work: a site coordinator can be given the ability to see and edit participants at their own site without any trial-wide access at all.

Roles and individual permissions combine. Someone with a role can also hold extra permissions on top, and their effective access is everything from both.

Changes save as you make them; Finish just closes the dialog.

Reading the personnel table

Each row shows the person, the roles they hold, and their permissions.

Two badges are worth recognising, because they mean access that does not come from this study at all:

  • Account manager — a team account manager, who has access to everything.
  • Team-level trial admin — someone holding trials.manage at team level, giving them administrator access to every study in the team.

Neither can be reduced from inside a study. If that access is wrong, it needs changing at the team level.

Below those, you will see the individual trial-scoped permissions they hold, followed by a summary badge per site and group — "Newcastle (4 permissions)" — so you can tell at a glance whether someone's access is trial-wide or scoped.

Removing someone

The bin icon removes them from the study entirely. They immediately lose access.

They stay a member of your team, so a team administrator can add them back later, but their study permissions are not remembered — you will need to set them up again. For someone leaving temporarily, it is usually better to reduce their permissions than to remove them.

Roles

A role is a reusable bundle of permissions. Rather than granting fifteen permissions to each of your six site coordinators, define a "Site coordinator" role once and assign it six times.

On the Roles tab, click Add a role for this trial. A blank role is created and opened for editing, where you give it a name, a description, and its permissions — using the same trial/site/group scoping as above.

The roles list shows each role's permissions as badges, with per-site and per-group permissions summarised by count.

Deleting a role removes it from everyone who holds it, and they lose whatever access it was granting. Anything they hold directly, or through another role, is unaffected. Check who is assigned before deleting.

Roles are defined per study. A role you create here is not available in your other studies — deliberately, since the sites and groups it references belong to this study.

A note on choosing permissions

Trialflare has a lot of permission keys, and the temptation is to grant trial.admin and move on. It is worth resisting for two reasons.

The first is least privilege: monitors who should not see direct identifiers, or coordinators who should not be able to delete participants, are ordinary requirements in a regulated study.

The second is that trial.admin does not include the PII permissions. Personal details, consent records and PII study fields each need granting explicitly, even to an administrator. Someone can be a full trial administrator and still find the Signed consents tab missing. That is by design, but it surprises people, so expect to grant those keys deliberately.

Roles and permissions documents every key in full, and is the reference to work from when designing your roles.

Permissions

To do this You need
View the personnel list trial.readUsers — also implied by trial.read
Add personnel Trial administrator (trial.admin, or trials.manage at team level), and users.list or users.create at team level to search for them
Remove personnel, and change anyone's permissions or roles Trial administrator — trial.admin, or trials.manage at team level
Invite someone to the study by email Trial administrator, and users.invite or users.create at team level
Invite new people to the team without adding them to a study users.create at team level — see Team permissions