This is the whole story, once, in order. Each stage links to the task guide that does it, and the workflows show the same story as hand-offs and gates.
The whole trial, from an empty platform to an archived study. Click any phase to see the responsible role, what happens, the audit footprint, and common alternate paths — then follow the link into the detailed workflow.
1. The organization is set up
An organization is created once, by the platform's operator, with one person: its first Organization Admin. It owns its people and its studies and can never see another organization's data; the separation is enforced by the database itself, not only by the application. The administrator signs in from an invitation and is guided through three steps: choose the roles the organization will use, invite the team, and create the first study. If the standard roles do not fit, a custom role can be composed from the same permission set, with two combinations blocked outright because they would break separation of duties.
→ Set up your organization · From platform to first study
2. The study is created and built
A study is created by an Organization Admin, who names its Project Manager in the same step, so the study never exists without someone to run it. It starts in Setup with Version 1.0 in Build. Setup is a workshop: the team can be staffed from the start, and the build team designs. There are no participants and no production data until the first version goes Live.
In Build the designer and the Project Manager do four things:
- Forms: draw the case report forms, or generate a first draft with AI, or copy one from the shared form library.
- Visit schedule: list the protocol visits with their day offset from baseline and the window each allows.
- Visit–form mapping: say which forms are collected at which visits.
- Rules: write the cross-form checks that run when data is saved.
→ Create a study · Build a study · Design forms · Plan visits
3. The design is frozen and tested in UAT
The design does not go live piece by piece. Forms, visits, mapping and rules are compiled together into one version with a content hash, and that version moves as a unit. Submit to UAT freezes it and opens a UAT cycle: a workspace of its own, with the same screens as Live, where the team registers test sites, enrolls test participants, captures data, raises queries and signs, all marked as test data that can never appear in a Live view. Testers raise issues; a cycle that fails returns the version to Build with its findings.
→ Review and release a study · Test a version in UAT
4. Three people sign the version off, and it goes Live
A version whose cycle passed needs three electronic sign-offs, by three different people in three capacities, each with a fresh code and bound to the exact design the cycle tested:
| Sign-off | Who signs it |
|---|---|
| Author | Project Manager |
| QA | Data Manager |
| Approver | Sponsor Manager |
No one else can sign, not even an Organization Admin. When all three are in, the version is Approved. The Project Manager registers and activates the Live sites, and then takes the version Live by typing its version number. The design becomes the one participants are captured under, the study becomes Active, and data captured from then on is production data.
→ Sign off a version and go live
5. Sites are opened
A site is registered first, which lets it do nothing. It can enroll only when it is activated, and activation needs a recorded ethics approval (a reference and date) and confirmation that GCP training is complete. There is no way round that gate. Site staff are then provisioned, but they have no access until the Principal Investigator signs their delegation of authority. The person who provisions and the person who authorizes are deliberately different.
6. Participants are enrolled
A participant cannot exist without a recorded informed consent date and ICF version. After screening, the investigator, and only the investigator, records the eligibility determination. An eligible participant is enrolled with a baseline date; an ineligible one is screen-failed with a reason and a criterion. At enrollment the system issues the participant number and dates the visit schedule from the baseline.
→ Screen a participant and record eligibility · Enroll a participant
7. Visits happen and data is captured
At each visit the coordinator opens the forms mapped to it and fills them in. When they Submit form:
- The visit's window is checked. Before the window opens, entry is blocked unless early access is recorded with a reason; a visit past its window is never blocked.
- Required values must be present, and the checks of the design run, on the server as well as in the browser. A check set to Block refuses the save, one set to Query lets it save and opens a query, one set to Warn saves with a message.
- Every changed value is written to the audit trail with the earlier value, the new value, who, when and why.
A saved value is read-only. It changes only while a live query raised by someone else is on it, and with a reason for change.
→ Run a visit · Enter visit data · Correct data
8. Data is cleaned through queries
A query is a question about a value. The study team raises them (monitors, data managers, medical officers, site monitors, the Project Manager), the site answers, and someone independent closes. The person who raised a query cannot answer it, and the one who answered cannot close it. Everything said on a query is kept in a thread nobody can edit. A query has a priority with a response time: critical 24 hours, high 48, normal and low 96.
9. Monitors verify against source
A Data Manager or Project Manager writes the SDV plan: which fields, on which forms, at which visits, are verified against the hospital's source documents. The monitor works a queue and records, for each, verified or discrepancy. The verification stores a hash of the value seen, so when the value changes it goes stale and returns to the queue. The person who entered a value cannot verify it.
10. Safety is recorded
An adverse event is recorded on its form. One that is serious is upgraded, which starts a reporting clock from the time the site became aware. The site reports outside Trialion and marks the report sent; follow-ups, a medical review and a reconciliation with the safety database are added as records; an overdue report or an unreconciled event blocks the database lock.
→ Record an adverse event · Safety reporting
11. Records are signed
When a record is complete the investigator signs it. Signing needs a fresh code sent to their email and their typed name; the signature records who signed, what it meant, exactly what was signed (as a fingerprint) and when. A later authorized correction withdraws the signature and the record needs signing again; nothing is silently carried forward.
12. The protocol is amended
A live study is amended by starting a new version in Build, built beside the Live one, tested in a cycle, signed by three people again and released. Going Live changes the configuration only: participants move to the new version one at a time, after re-consent where the amendment asks for it, and data already captured stays tied to the version it was captured under.
13. The study closes and the database is locked
The study can be put on hold, closed to enrollment and finally completed, which ends new data except through a query. When the data is clean, the lock takes two different people, each with an e-signature: one asks, a second confirms. Some things block it: open queries, overdue or unreconciled serious events. After the lock nothing is written. A locked study can be unlocked, again by two people, and finally archived by the Organization Admin as read-only. Exports stay possible throughout.
→ Export data · Change the state of a study · Close and lock a study
What is recorded throughout
Every one of these steps writes to an audit trail, and each entry is cryptographically chained to the one before it. Inserting, removing or altering an entry breaks the chain, and an auditor can run the verification without asking an administrator.