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. Only people who are already members of your Trialflare team can be added to a study. If someone is not in the list when you search, they need inviting to the team first — see User management.
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.
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.
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.manageat 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 or remove personnel, and change anyone's permissions or roles | Trial administrator — trial.admin, or trials.manage at team level |
| Invite new people to the team | A team-level permission — see Team permissions |
Related articles
- Roles and permissions — every permission key, explained
- Sites — site-scoped access for multi-site studies
- User management — inviting people to your team
- Getting started — Part 10: Team members, collaborators and sites