What this is, and who it is for
A form has a short life of its own (Draft, Active, Archived), and it belongs to a version of the study, which has the long one: Build, UAT, Awaiting sign-off, Approved, Live. The form's status says whether its content may still change and whether it can be used; the version's state says whether anything in the design may change at all. This page joins the two, and says what "publishing" means in Trialion: there is no publish button on a form. A form is made active, and a version is submitted to UAT, signed off and released. This page is for the designer and for the person who signs off the result.
Where to find it
Study → Build → Forms: each row shows the form's code, its version label and status badge, its field count, and a menu of actions. Open a form for its page: Version, Description, Preview, the actions for its status, and Maintenance. The version's own steps (Submit to UAT, Go live) are on Study → Versions.
What you can do
| Action | Form status it applies to | Needs | What it does |
|---|---|---|---|
| Make active | Draft | form.publish, form.design or study.write | Checks the design first, then marks the form Active so it can be mapped in the version in Build |
| Reopen for editing | Active | the same | Takes an Active form back to Draft only while the study has never released a version; its visit bindings are set aside |
| Archive draft (also shown as Remove in the Forms list) | Draft | the same | Retires an unused draft. It is kept for the audit trail and left out of normal lists |
| Edit form details | Draft | form.design or study.write | Code, display name, description, category, CDISC domain tag and whether it is an event form |
The server checks the status transition and the permission; the screen offers only the actions that would not be refused.
Every option
A form's status
| From | Can move to |
|---|---|
| draft | active, archived |
| active | draft |
| archived | (none: final) |
- Draft: the form's design can be edited in the builder (if its version is in Build). It cannot yet be used to capture data.
- Active: the design is fixed. It can be mapped to visits and, once the version is in UAT or Live, used to capture data.
- Archived: retired and final; kept, left out of the design.
What Make active checks
The dialog Make code active? lists the errors the builder finds (duplicate variables, a choice with no options, a broken or circular formula, a table with no columns and so on: Preview and testing) and does not let you continue while there are any. The server repeats the structural ones and refuses an activation that has them. A form with only warnings is activated.
Reopening, and why it is limited
Reopen for editing is offered only if the design is editable (a version in Build) and the study has never had a Live or superseded version. After a release, a form that was part of it is history: it is changed through an amendment, which makes a new version in Build with its own working copy of every form. Reopening sets the form's bindings to visits aside while it is a Draft; Make active puts them back. A reopened form that is left a Draft with no bindings will be reported when the version is submitted (Form X is not held by any visit; its visit bindings were set aside: make the form active again to put them back).
The form's version label
Each form carries a version label (for example 1.0) shown beside its status. An amendment gives each form a new version that starts with no bindings to visits. The label shows which version of the form a participant's record was captured on, and data stays tied to it.
What an amendment may change in a form
In an amendment the working copy of each form is a draft whose fields are checked against the Live form:
- A field that exists in the Live version cannot be deleted: it may hold data. It is deprecated instead, with a reason that is recorded; a deprecated field is hidden from people entering data, kept in the design and its data stays readable and exportable.
- Every change is classified in the amendment's change summary by what it does to data already captured:
| Impact | Examples |
|---|---|
| Low | A label, help text, description, placeholder, position, layout, section, a hidden-in-builder flag, the message of an inactive field, the wording of a check message, a field no longer being required, a field added that is not required |
| Controlled | A field that became required or was added as required; a check added or changed; a check's severity changed; a rule that sets the field changed; a formula, default value or comment setting changed; an option or a table column or row added; a unit given; a field deprecated |
| Breaking | The type of a field that holds Live data changed; a code-list value removed that Live data uses; a unit changed or removed on a field with Live data; a column or row removed from a table with Live data; a field deleted; an event form changed so it no longer fits recorded events |
A Breaking change is refused when the version is submitted to UAT and again at go-live, naming the field and what to do instead (Add a new field and deprecate this one instead). The type-change dialog in the builder does this for you (Field types).
How a design is published
- Build. Forms, visits and bindings are edited as Drafts. Each save is a revision.
- Submit to UAT. In one transaction the version's draft forms are made active, the whole design is read and checked (the list in Preview and testing), compiled into a snapshot with a content hash, and a UAT cycle is opened on it. From this moment the design is frozen.
- UAT. The snapshot is tested against test participants. Passing the cycle moves the version to Awaiting sign-off; failing it returns it to Build.
- Sign-off. Three different people (author, QA, approver) sign the snapshot's hash.
- Go live. The approved version becomes the study's Live version and participants are enrolled on it.
Changing anything in the design after step 2 is a new submit, a new snapshot and a new cycle. See Review and release a study.
What is frozen when
| Version state | Forms | Bindings | Builder |
|---|---|---|---|
| Build | Draft forms editable; Active forms reopened if never released | Editable | Opens for editing |
| UAT, Awaiting sign-off, Approved | Locked: the version is under test; fail its cycle or reject the sign-off to return it to Build | Locked | Read-only with that notice |
| Live | Sealed: start an amendment to change forms | Sealed | Read-only |
| Superseded, Withdrawn | History | History | Read-only |
What the system records
form.created, form.transitioned (every status change, with who and when), form.draft_saved (each save) and study_form.field_deprecated / study_form.field_restored (with the reason) are written in the same transaction as the change. Submitting, passing, signing and going live are version events (study.version.submitted_to_uat, study.version.went_live and the rest: Audit events).
What you cannot do, and why
- Change a form in a version that is under test or Live. What was tested and signed is what runs.
- Reopen a form after the study has gone Live. Use an amendment.
- Delete a field that a Live version had. Deprecate it.
- Change the type, remove an option or change the unit of a field that holds Live data in an amendment. It is a breaking change; add a new field.
- Activate a form with errors.
- Skip UAT. There is no route that releases a version without a passed cycle and three sign-offs.
Compliance Q&A
Yes. A released design changes only through an amendment, which is a new version that is submitted, frozen as a hash-stamped snapshot, tested in a UAT cycle, signed by three different people and then released. Each change is classified by its effect on captured data and the dangerous ones are refused.
Evidence: server/src/modules/study/versions (ADR 0012: submit to UAT, snapshot hash, UAT cycle, three sign-offs, go live)versions/domain/change-impact.tsforms edit-form.ts (field protection)
No. A field inherited from a released version cannot be deleted; it is deprecated with a recorded reason, hidden from entry and kept, so captured data stays readable and exportable.
Evidence: server/src/modules/study/forms/application/commands/edit-form.ts (assertFieldChangesAreSafe)audit events study_form.field_deprecated
Related
Overview · Preview and testing · Binding a form to visits · Amend a live study · Review and release a study · Statuses