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, when they first logged in to the app, 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, and Unallocated are written out, and the rest are small icons — hover over any of them for the detail:

  • a green person with a tick — they have joined (opened the study at least once); the tooltip gives the date they first did
  • a purple bell — their device is registered for push notifications
  • a red clock with an exclamation mark — they are behind on at least one stage; the tooltip says how many stages and how late
  • a blue clock — something is due soon; the tooltip gives the dates
  • a book — the casebook's signature status: green with a tick when every response is signed, otherwise the number signed out of the total
  • a logo or watch per connected wearable service, with when it last synced
  • a red watch — Garmin is switched on for this participant (for the whole trial, or for one of their groups) but they haven't connected their Garmin account yet

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, including each participant's first login date.

Finding people

Search matches on participant ID.

Filter opens a panel with four groups of options:

  • Schedule: behind schedule, on schedule, or due soon. Due soon means something falls due in the next 7 days (see Due soon). Participants with something due soon carry a blue clock in the table, and hovering over it gives the dates.
  • 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.

Automatic membership

A group can fill itself. When editing the group, tick Add participants automatically and choose what adds them:

  • When they give a particular answer on a form. Choose a stage and set the condition, such as "Procedure type is equal to one of E_POEM" on the Diagnosis stage. The condition works exactly like a field's Show if condition on a stage.
  • When they complete a particular stage. Choose the stage, and for one that repeats or is anchor-scheduled, optionally which occurrence, such as the fourth follow-up. A participant joins once they have a response to it, and leaves if that response is deleted.
  • When all their stages are complete. The same as Completed on the trial overview: every stage that counts towards their progress is done. Ad-hoc stages never count, and staff-only stages count only if the study counts them.
  • When they complete their first stage. The same as Started on the overview: at least one stage that counts towards their progress is done. Useful for an "Onboarded" group.

A group that follows progress can't also be used to decide which stages participants see: scoping a stage to it would change their progress, which would move them in and out of the group. Such groups aren't offered when scoping a stage.

For a rule based on an answer, from then on:

  • A participant joins when one of their responses to that stage meets the condition, whoever entered it. On a form filled in more than once, one matching submission is enough: a later one that doesn't match doesn't take them out.
  • A participant leaves if the answer changes, or the response is deleted, so that none of their responses meets it any more. Correcting a mistyped answer moves them to the right group.
  • A response must actually answer the field. A blank answer never puts anyone in a group, even with "is not equal to".
  • People you add by hand stay. Adding someone to the group yourself takes their membership out of the rule's hands: the rule never removes them.
  • People you remove by hand can come back. Taking someone out of the group only lasts while they don't meet the rule. If they still do, they rejoin the next time the rule is checked for them, for example when their form is saved again or the rule is changed. To move someone for good, correct the answer the rule reads, or turn the rule off.
  • Participants already in the study are checked straight away, in the background, when you save a new or changed rule.
  • Turning the rule off leaves everyone it added in the group, as though you had added them yourself.

A rule based on progress follows it the same way. A participant joins when their progress reaches the point, and leaves if it falls back, for example because a response is deleted or a new stage is scheduled for them. The same exceptions apply: people added by hand stay, people removed by hand rejoin if they still meet the rule, and turning the rule off keeps its members.

In the participants table, a group a rule added someone to carries a small lightning icon on its tag; hover over it to confirm. Adding someone by hand clears it, because the membership is then yours rather than the rule's.

Every automatic join and leave appears in the trial's event log as a group membership change made by the system, with the rule that caused it.

Combined with stage scoping, this routes participants to their own forms without anyone having to place them: scope each set of forms to a group, and let the answer that decides which forms apply fill the group. Recipe: branching a study on an answer walks through it end to end.

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, stops stage reminders and automatic messages, and excludes their data from exports. It is the right tool for records created in error or participants who never started.

Withdrawing stops stage reminders and automatic messages, and prevents the participant submitting anything further — but staff can still update data on their behalf, and their existing data stays in exports. Your team can still message a withdrawn participant by hand, for example to confirm their withdrawal. 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.

Archiving or withdrawing a participant takes them out of the Participant journey figures on the trial overview, and out of the behind-schedule count under Needs attention on your home page. Completion percentages therefore describe the participants still taking part. The home page count changes straight away; the Participant journey panel catches up at its next refresh. "Registered participants" in Key information still counts every record.

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. By default it lists the stages available to the participant; if the study counts staff-completed forms, it lists those too. 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.