How a running study changes, and how it stops. Both are forward-only, and the last steps need two people.
Amending a live study
A live study is never edited in place. The next version is built beside the one in use, tested, signed and released like the first; then the participants are moved to it, one site at a time or all at once.
The study never leaves Live while this happens. Participants keep working on 1.0 until they are moved; going Live promotes the configuration only, and no participant moves by itself. A participant who has moved keeps their earlier data, tied to the version it was captured under; their visits that never took place are retired and replaced by the new version's.
Breaking changes are refused. A change that no longer fits data the study holds (a field's type, a removed option, a changed unit, a deleted field that holds Live data) is refused at the submit to UAT and again at go-live; the answer is to add a new field and deprecate the old one (Amend a live study).
The 'protocol' in Trialion is the executable study version. It pins the design (forms, the visit schedule, their mappings, rules and settings), is tested in a UAT cycle, sealed with a content hash, signed off by three people and released. Participants' data is bound to the version they were collected under.
Closing and locking
What each state actually permits
| State | Enroll | Enter and correct data | Queries, verification, signatures, safety, deviations | New versions |
|---|---|---|---|---|
| Setup | No | No Live data | Design work only | The first is built |
| Active | Yes | Yes | Yes | Yes |
| On hold | No | Yes | Yes | Yes |
| Closed to enrolment | No | Yes | Yes | Yes |
| Completed | No | Only by answering a query | Yes | No |
| Locked | No | Nothing is written | No | No |
| Archived | No | Read-only | Read-only | No |
Hold stops enrollment only; it does not stop cleaning. Closing to enrollment is the same for data. Completing the study ends new data: a record is then corrected only by answering a query, which is what close-out is for. Locking stops everything.
The two-person lock
One person asks for the lock with an e-signature; a different person with the right confirms it with theirs. The same person cannot do both. The request lists what is open, and some things block it: open, reopened or escalated queries, serious adverse events with an overdue initial report, and serious adverse events not reconciled with the safety database. Unsigned records and unverified source data are listed and acknowledged, not blocking. Each person is shown the list as it is when they sign, and a signature made on a stale list is refused. The unlock back to Completed works the same way, with two people.
Every state move needs a written reason, and the lock and unlock need an e-signature for each of the two people. Archiving is the Organization Admin's alone (Close and lock a study).
A study has one state at a time. It starts in Setup and becomes Active by itself when version 1.0 goes Live; every other move is a person's audited act with a written reason. What each state allows is decided in one place and enforced again by the database, so a bug in a route cannot write what the state forbids.
The study exists and is being prepared: the team, the documents and the design of version 1.0. There is no Live data yet.
Version 1.0 is Live. Participants are screened and enrolled and data is captured.
Enrollment is paused; everyone already enrolled carries on, and version work is still allowed.
No new participants; data entry and cleaning continue for those already enrolled.
Data entry has ended. Queries, source data verification, signatures, safety reporting and deviations continue, and a value is corrected only by answering a query.
The database is frozen by two different people, each signing with a fresh code, on the same list of what was still open. Nothing can be written. Unlocking also takes two people and returns the study to Completed.
Kept for retention and read-only. This cannot be undone in the interface.
Terminal — no transitions out.
Getting the data out
Exporting is not the same permission as running an export.
| Who | Can run an export | Can download one already produced |
|---|---|---|
| Organization Admin, Project Manager, Data Manager, Regulatory Manager | Yes | Yes |
| Sponsor Manager, Sponsor Supply Manager, Auditor | No | Yes |
Three formats are produced: Excel, CSV (zip) and CDISC ODM-XML. SAS .xpt, define.xml, PDF and signed exports are refused rather than produced (Not built yet). A ready export expires after seven days. An export is a read, so a locked or archived study stays extractable.
Where this goes wrong
| Symptom | Cause |
|---|---|
| "The design won't let me edit it" | You are on the released version. Start an amendment |
| "The amendment is refused at go-live" | A breaking change, or the SDV plan names something the new version does not have |
| "Some participants are still on 1.0" | They have not been moved: re-consent is not recorded, they declined, or the move has not been run |
| "The lock won't go ahead" | Something blocks it (open queries, overdue or unreconciled serious events), or the same person tried to confirm their own request |
| "The study won't complete" | A version still being built or tested must be withdrawn first |
| "The export link is dead" | A ready export expires after seven days. Run it again |
Do it
Amend a live study · Change the state of a study · Close and lock a study · Export data
Compliance Q&A
Yes. The amendment is a version with its own build, UAT, sign-offs and snapshot hash. The Live design stays in force until the new one goes Live, and participants move to it individually, with their earlier data kept against the version it was captured under.
Evidence: server versions (amendment cloned from Livebreaking changes refusedparticipants move individually and keep earlier data tied to their version)simulation of 20 Oct 2026, steps 6.14 and 6.15
Yes. The request and the confirmation are two signatures by two different people, each on the listing as it was when they signed, and the lock writes both to the audit trail.
Evidence: server studies (lock request and confirmation by two different people, each with an e-signaturefingerprint of the listing)simulation of 20 Oct 2026, step 8