Participant management

The Participants area is where you register people into your study, organise them, and open any individual participant's record. It has up to three tabs: Participants (the table), Participant groups, and Participant resources where that feature is enabled.

The participants table

One row per participant, with a count badge on the tab showing how many there are.

Column What it shows
ID The participant's identifier — click it to open their record
% Progress through their scheduled stages, as a ring
Status Badges (see below)
Seen When they last opened the study, and roughly where from
Sites Site tags, with controls to add and remove
Groups Group tags, with controls to add and remove

Status badges tell you the participant's state at a glance: Archived, Withdrawn, Unallocated, Joined (they have opened the study at least once), Behind (at least one stage is overdue), Push (their device is registered for notifications), and a badge per connected wearable service.

Sort by ID, progress, or last seen using the column headers. The download icon at the right of the header row exports the table as a CSV.

Finding people

Search matches on participant ID.

Filter opens a panel with four groups of options:

  • Schedule — behind schedule, or on schedule.
  • Allocation — unallocated, or allocated.
  • Joined — not joined, or joined.
  • Withdrawn — withdrawn, or not withdrawn.
  • Show archived — archived participants are hidden by default; this brings them back.

Alongside are site and group filters. Group filters are three-state — click once to include that group, again to exclude it, and a third time to clear. There is also a No group option for finding participants who have not been assigned to any. Applied filters appear as removable chips above the table, with a count on the Filter button, and Clear filters resets everything.

You can also click any site or group tag in the table to filter to it directly.

Saved filters

Once you have a view you use regularly — "behind schedule at my site", "not yet joined" — Saved filters stores it under a name, including the search term and sort order.

Any saved filter can be marked as your default, in which case it is applied automatically whenever you open the participants table. You can also overwrite an existing saved filter with your current settings rather than creating a new one.

Creating participants

Register participants offers three routes.

One at a time

Enter a participant ID, and optionally a password and a group.

If you set a password, make a note of it — Trialflare cannot reveal it later. Leave it blank to use the study-wide password, if you have one.

In bulk, generated

Say how many you want (up to 2000 at a time) and choose how IDs are generated:

  • Random three-word phrase — memorable, easy to read out over the phone.
  • Sequential pattern — {n} becomes a sequential number, and {3p} pads it with leading zeros to three digits, so p{3p}{n} gives p001, p002.
  • Random alphanumeric — of a length you choose, five characters by default.

If you have groups defined, you can also choose a grouping strategy at the same time: add everyone to one group, round robin through them in turn, random uniform allocation, or random blocks of a size you pick. This is how most studies do their initial allocation.

Ticking Generate random passwords downloads a CSV of IDs and passwords as soon as the participants are created. Keep it safe — those passwords cannot be retrieved afterwards.

From a CSV

Upload a file with a participantId column, and optionally group and password columns.

In all three routes, duplicate participant IDs are ignored rather than causing an error, so re-uploading a file only creates the rows that are genuinely new.

Creating participants in advance is normal. Many studies pre-create a pool of participant records and allocate them as people are recruited — which is exactly what the Unallocated status is for, and what screening questionnaires draw from when they turn a submission into a participant.

Sites and groups

Groups are tags for organising participants — study arms, cohorts, or any label you find useful. Sites are the locations taking part; see Sites.

Both work the same way from the table:

  • On a single row, the + button adds the participant to a site or group, and the × on an existing tag removes them.
  • Selecting several participants with the checkboxes puts Add to and Add to site: in the bulk menu.

A participant can belong to any number of groups and sites.

Managing groups

The Participant groups tab is where groups are created and edited. Each has a name and a colour, which is what you see on tags throughout the interface — worth choosing deliberately if you have several arms. View participants jumps to the table filtered to that group.

Acting on several participants at once

Select participants with the checkboxes, then use the menu in the header row. Select all on page selects the current page only.

Action Effect
Send push notification Notifies the selected participants
Add to group / Add to site Assigns all of them
Archive / un-archive See below
Mark as withdrawn / unmark See below
Delete participants Permanent

Archiving hides participants from the table by default, stops any new data being submitted, and excludes their data from exports. It is the right tool for records created in error or participants who never started.

Withdrawing stops automatic stage reminders and prevents the participant submitting anything further — but staff can still update data on their behalf, and their existing data stays in exports. This is the tool for someone who has withdrawn from the study proper.

Both are reversible, and both skip participants already in the target state, so re-archiving does not reset the original timestamp.

Deleting is not reversible and removes the participant along with their data. You are asked for a reason, which is recorded in the trial's event log (Settings > Logs) with the participant's ID and the list of responses removed — so the log shows who was deleted and why. The participant's record itself is not copied into the log: deleting a participant is how you honour a request to erase their data. Nothing can be deleted while the trial's database is locked.

Withdrawn participants still count in the Participant journey figures on the trial overview. Archived ones do not. It is worth knowing which you have used when you come to quote completion rates.

The participant record

Clicking a participant ID opens their record, which has its own set of tabs.

Information

The main summary, and where most day-to-day management happens.

At the top: their ID, status badges, when they were last seen, whether a password is set, which contact channels are available (push, email, SMS, WhatsApp), and their groups and sites. Personal details — name, date of birth, email, phone, WhatsApp — appear here only if you hold the PII permission.

Edit details opens a dialog covering:

  • Participant ID — changeable after creation.
  • Personal details — name, date of birth, and contact details.
  • Timezone — which governs when scheduled stages and reminders reach them.
  • Login password — set a new one, or save while blank to remove it.
  • Anchor dates — set or clear each anchor for this participant, which recalculates any stages scheduled from it.

Login link generates a direct link the participant can use to get into the study, and can be re-generated if needed.

Further down: Packs assigned to them, connected services such as wearables, their messages with the study team, notes (staff-only, and permission-gated separately from the rest of the record), and a recent activity log.

Typing @ in a note offers the people on your study, and whoever you name is notified. Only people who can already read this study's notes can be mentioned; the notification says who mentioned you and on which participant, and doesn't carry the note's text. See Mentioning people.

Responses

Everything they have submitted, and where staff enter data on their behalf. If you have defined stage groups, they appear here as tabs — one per visit — which is the main reason to set them up. Add data for this stage form opens the form for staff entry.

Timeline

Their schedule: timepoints with a completion percentage, plus any ad-hoc stages. Each timepoint shows as Completed, Available, Pending, or Expired — expired meaning its availability window has closed, so the participant can no longer submit but staff still can.

Wearable responses

Data from connected devices, where the participant has linked one.

Their signed consent, with a download link, plus identity verification details where that was used. Requires the participant consent permission.

Other tabs

Food diaries appear where the feature is enabled for the study, Meetings lists their video calls, and Incentives shows any vouchers issued to them.

Permissions

To do this You need
See the participants table trial.readParticipants — also implied by trial.read
Register new participants trial.registerParticipants, or site.registerParticipants on a site
Edit participant details trial.writeParticipants
Add and remove groups trial.tagParticipants
Assign sites trial.write
Mark allocated / unallocated trial.allocateParticipants
Archive and un-archive trial.archiveParticipants
Mark as withdrawn trial.withdrawParticipants
Delete participants Trial administrator, or trial.deleteParticipants
See names, contact details and dates of birth trial.readParticipantPersonalInformation (PII)
See their consent record trial.readParticipantConsent (PII)
View and add notes trial.readParticipantNotes / trial.writeParticipantNotes
View their responses trial.readParticipantStudyData
Enter data on their behalf trial.writeParticipantStudyData
Set or clear their anchor dates trial.writeParticipantStudyData
Reschedule their stages trial.rescheduleParticipants
Export the table as CSV trial.read

Opening a participant's record while you hold trial.readParticipantPersonalInformation is itself recorded in the trial's event log (Settings > Logs), as a readParticipantPersonalInformation entry naming the fields that were shown. Nobody without that permission sees those fields, and nothing is logged for them.

Site-scoped staff can do much of the above for participants at their own site without any trial-wide keys. See Roles and permissions.