Skip to content
ImplementedFor testers (site staff, data managers, monitors), project managers

Test a version in UAT

Last updated Oct 21, 2026

What this is, and who it is for

When a version is submitted, the system opens a UAT cycle on its frozen snapshot and gives the study a UAT workspace: a separate world with the same screens as Live, in which people enter test participants and test data to find out whether the design does what the protocol needs. Nothing entered in UAT appears in any Live view, export or count; the two are kept apart in the database. A cycle ends passed or failed. Failing returns the design to Build; passing asks for the three sign-offs.

You needTo
A role on the study in UAT (the study team's roles are held in both workspaces; test site staff are added in UAT)Enter the UAT workspace
study.uat_issue.writeRaise, edit, resolve, accept and reopen issues
study.uat_issue.readSee the issues
study.uat.close_cyclePass or fail the cycle

Held by: Organization Admin, Project Manager, Clinical Research Associate, Data Manager, Principal Investigator, Clinical Research Coordinator (study.uat_issue.write).

Held by: Organization Admin, Project Manager (study.uat.close_cycle).

Where to find it

Study → Versions, the version in UAT, the UAT row (a cycle's own page is titled UAT cycle {n}) of the stages table, Enter. Entering asks first: a dialog names the area and the version, the role you will work as, and whether you will find it editable or read-only, with the reason. A session is in one workspace at a time; entering one starts a new session, which opens at that workspace's dashboard. The banner of the workspace says UAT and the screens say test data.

What you can do

Prepare

The Project Manager adds the testers to the study team (the study team is held in both workspaces) and the test site staff inside a UAT site: register a test site, activate it, add its investigator and coordinators, and have the investigator sign their delegations exactly as at a real site (Open a site, Staff a site). Sites registered in UAT are test sites; they do not count toward Live.

Where: UAT workspace. Role: Project Manager.
Where: UAT workspace (cycle 1). Role: Project Manager.

Test

The UAT dashboard says This workspace holds test data only. Enter test subjects and records at your site, answer the queries the checks raise and, if something is wrong, raise an issue. It shows Test subjects (enrolled in this cycle), Test records (forms entered by testers), Test queries, Test signatures and Open issues, and the screens of the workspace: Test sites, Testers and team, View the frozen design.

Test the protocol, not the buttons: screen and enroll test participants, run each visit, enter normal and abnormal values for every check, let the edit checks open queries, answer and close them, sign and lock a record, record an adverse event and upgrade it to serious, try the roles that must be refused. Everything that works in Live works here.

Raise issues

Choose Raise issue on Issues (a screen of the workspace):

FieldNotes
TitleWhat went wrong, in one line
How serious is it?Critical, Major or Minor
DescriptionWhat you did, what you expected, what happened instead
Seen on a test subjectOptional: choose one of this cycle's participants, or None. It cannot be changed afterwards

The list can be filtered by status (open, resolved, accepted), severity and a search, and for any cycle. Each issue has actions: Edit issue, Resolve, Accept… (accept as it is, with a reason) and Reopen. A summary counts Critical · open, Major · open, Minor · open, Resolved and Accepted.

Where: UAT workspace > Issues > Raise issue. Role: Clinical Research Coordinator (UAT).
  1. Records the issue against the open cycle.

Pass or fail the cycle

On Versions or the UAT dashboard, the Project Manager (or Organization Admin) chooses:

  • Fail cycle: The version returns to Build so the design can be corrected; resubmitting opens the next cycle with a new snapshot. The cycle's test data stays, read-only. A reason is required. The issues become the corrections to make (Correct a design after UAT).
  • Pass cycle: The design is as the testers expected. The version goes to sign-off: Author, QA and Approver, three different people, each binding their signature to this cycle's snapshot. (Sign off a version and go live).

A cycle cannot be passed while a critical issue is open: the database refuses (cycle.critical_issues_open). Resolve the issue, or accept it with a reason, and the cycle can pass. Open major and minor issues do not stop a pass: the decision is the team's, and an issue left open or accepted is part of the record.

Where: Study > Versions > v1.0 > Pass cycle. Role: Project Manager.
Where: Study > Versions > v1.0 > Fail cycle. Role: Project Manager.

See how a cycle went

Results (UAT only) shows a Cycle report for each cycle: test data written (participants, records, queries, signatures), issues found (by severity), the outcome and the sign-offs, with View issues. A closed cycle stays, read-only, for ever, and can be opened from the stages table for review.

Where: Study Versions > Version 1.0 > Cycle 1. Role: Project Manager.
Where: Study Versions > Version 1.0 > Cycle 2. Role: Project Manager.
Where: UAT workspace > Closed cycle (version 1.0, cycle 1, failed) > Overview. Role: Project Manager.
Where: UAT workspace > Closed cycle (version 1.0, cycle 1, failed) > issues. Role: Project Manager.

Every option

What UAT does not do

UAT does not email anyone differently, does not use different checks or a different design, and does not change a Live participant. Its data is stamped as test data: the audit trail, queries and signatures of UAT are real records of the test and are kept with the cycle.

What a tester can and cannot see

Each person sees UAT as their role does in Live: a site coordinator sees their own test site, a study-level role sees the study’s test sites, and so on. The Organization Admin holds no study role, so is not a tester.

What the system records

uat.cycle.opened, uat.cycle.passed / uat.cycle.failed (with the reason), uat.issue.raised, uat.issue.updated, uat.issue.resolved, uat.issue.accepted, uat.issue.reopened, and everything the testers do, exactly as in Live but stamped UAT. The cycle's snapshot hash and the test data stay with the cycle.

What you cannot do, and why

  • Change the design in UAT. It is frozen on the snapshot being tested.
  • Move test data to Live, or see Live data from UAT. They are separate by construction (ADR 0013).
  • Pass a cycle while a critical issue is open. Resolving it, or accepting it with a reason, lifts the block.
  • Fail a cycle without a reason, or close a cycle that is no longer the open one (a second tester pressing an old button is told the state it found).
  • Skip UAT. A version cannot go Live without a passed cycle.

Compliance Q&A

Compliance Q&ABuiltPart 11 11.10(a)Annex 11 4Annex 11 11ICH E6 computerised-systemsALCOA+ accurate
Is the system tested for its intended use in an environment kept apart from real data?

Yes for each study's configuration. A UAT cycle runs the frozen design with test participants in a workspace that no Live view, export or count can see; a failed cycle is kept as evidence and the next one starts on a new snapshot.

Limits: this validates the study's configuration. Validation of the platform software itself (installation and operation qualification) is not supplied; see GAMP 5 and validation.

Evidence: server versions module (UAT cycle on a snapshot, workspace isolation ADR 0013)simulation of 20 Oct 2026 (two cycles, one failed)

Review and release a study · Sign off a version and go live · Correct a design after UAT · Finding your way · Environments and versioning