DocsRun a studyTest mode

Test mode

Every draft study is a sandbox. Rehearse the full participant experience with test data that never mixes with real data.

Every draft study in TrialPilot is a sandbox. Before anything is real, your team can enroll as test participants on real devices, complete the screener and consent, receive the actual schedule of check-ins and assessments, and watch the flagged data land on the dashboard. If you have used test mode in a payments platform, this will feel familiar — with one difference in stakes: stray test data in a clinical dataset is a data-integrity problem, so TrialPilot treats “test data can never appear in a real dataset” as a guarantee, not a convention.

How test mode works#

Test mode is built around three ideas:

  • A separate invite code. Enabling the sandbox generates a dedicated code in the form TEST-XXXXXXXX. The study's real invite code does not work while the study is in draft, and sandbox materials only ever carry the TEST code.
  • A tester allowlist. Only email addresses you add as testers can redeem the TEST code. Anyone else who tries sees that the study is still being set up.
  • Write-time flagging. Every record a tester creates — enrollment, consent, check-ins, assessment responses, symptom reports — is stamped as test data at the moment it is written, and that stamp never changes. Separation does not depend on remembering which study was in draft later.

Start testing a draft study#

  1. Finish enough of the Study Builder that the study is testable.
  2. Enable the sandbox for the study to generate its TEST code.
  3. Add your team members' account emails to the tester list.
  4. Have each tester install the TrialPilot app and join with the TEST code.
  5. Complete the real participant flow: screener, consent, baseline tasks, daily check-ins, and scheduled assessments.
  6. Watch the results arrive in the dashboard, clearly in a test cohort.

The test experience deliberately matches production: the screener, consent capacity checks, and study plan behave exactly as they will for real participants, so what you learn in rehearsal transfers. The only gates a sandbox skips are the ones that exist to protect human subjects and enrollment counts — testers are team members exercising software, so sandbox enrollment bypasses publication approval, the IRB activation gate, and enrollment slot caps, and it never touches registries.

Rehearse the whole study, not just day one

Test mode is most valuable for catching schedule problems: an assessment that lands on the wrong week, a burden level that feels unrealistic, or consent language that confuses a reader. Let at least one tester live with the study for several days before you publish.

What test data looks like#

SurfaceBehavior in test mode
DashboardA draft study’s dashboard shows its test cohort. Small-cohort suppression does not apply, so you can inspect individual test participants freely.
ExportsA draft study's export is always the watermarked sandbox export: the filename is prefixed SANDBOX_, the first line of the data file carries a notice, and the manifest is marked as test data.
Consent receiptsA test signature renders with a diagonal SANDBOX — NOT A VALID CONSENT watermark, so a rehearsal document can never pass as a real consent record.
Safety workflowsTest symptom reports and adverse events are flagged and never create real safety or reporting obligations.
Metrics and randomizationPlatform metrics, results summaries, recruitment funnels, compensation, and randomization allocations all exclude testers unconditionally.

Wearable data works differently on purpose. A tester's wearable samples are never stamped with the study — they bank as that person's own personal baseline. The sandbox dashboard reads the test-window slice of that baseline, which makes study-scoped wearable contamination structurally impossible, and means a tester who later joins for real starts with their baseline already collected. See Monitor participants for how wearable coverage appears once the study is live.

What happens when you publish#

Publishing a sandbox-tested draft converges everything to a clean production state:

  • The study becomes recruitable on its real invite code, with enrollment counts starting from zero — test enrollments never counted.
  • The TEST code is revoked permanently and can never be reissued, so a code circulated during rehearsal can never resolve to a real enrollment.
  • Test enrollments are completed automatically, and the test data is purged 90 days after publication. Personal banked wearable data and the append-only audit trail are never purged.
  • Testers get a one-tap “join for real” offer in the app. Accepting creates a clean new enrollment, and the participant is marked as previously tested in the de-identified enrollment view and roster export — because someone who has seen the instruments before may respond differently.

Keep the sandbox export if you need a record

The publish-time watermarked export is your durable record of the rehearsal. After the retention window, purged test data is gone. A published study's exports exclude test data unless you explicitly request the sandbox record during its retention window.

Rules and limits#

  • A tester cannot hold a real active study enrollment and a test enrollment at the same time — test enrollments occupy the same one-active-trial slot as real ones, deliberately, for full behavioral parity.
  • Re-enrolling in the sandbox after withdrawing replaces the earlier test run.
  • Trashing a draft ends its sandbox the same way publication does, including revoking the TEST code; permanently deleting the draft purges test data immediately.