Two people can sign in to the same study and see different menus. That is deliberate, and there are only three reasons for it.
Why your menu differs from a colleague's
1. Your role. Every screen requires a specific permission. If your role does not hold it, the screen is not listed, and typing its address does not get you in. Nothing is hidden but reachable; access fails closed (Screens and who sees them).
2. Where you are in the study. A study has three areas, each with its own menu: Build (the design of one version), UAT (that version under test, against test data) and Live (the released version, against production data). The study's own page, the Overview, lists its versions, and each area is entered from there. UAT and Live have the same screens; the issues testers raise exist in UAT only, and a site's own team log exists in Live only.
3. Whether you are site staff. Site Team, the delegation-of-authority log for your own site, appears in the menu only for people scoped to a site (the investigator, the coordinator, the pharmacist). Everyone else reaches a site's staff list from Sites → the site → Staff.
The two levels
Trialion has an outer level (your whole organization) and an inner level (one study).
Organization level
The menu groups the organization's screens: Portfolio, Design, Governance and Administration. Everyone lands on Studies; the figures and reports of a study are inside the study.
| Menu item | Group | What it is | Who sees it |
|---|---|---|---|
| Studies | Portfolio | The studies you have access to, the ones that need attention first, with the role you hold on each and the totals your role works from | Anyone who can read a study |
| Form Library | Design | Reusable form templates shared across studies | Form designers and readers |
| Organization Audit | Governance | The organization's own audit trail | Organization Admins |
| Roles & Permissions | Administration | The role catalog and custom roles | Organization Admins |
| Organization Team | Administration | Your organization's people | Organization Admins |
| Access | Administration | Who holds what, and the exceptions | Organization Admins |
| Settings | Administration | Your account, how you sign in, where you are signed in | Everyone |
Inside a study
Open a study and you land on its Overview: the study, and each of its versions as a card. Opening a version's stage (Build, a UAT cycle, Live) takes you into an area, and the menu changes to that area. Every area's menu starts with ← Study overview.
The study level: what is true of the study whatever its versions.
| Menu item | What it is |
|---|---|
| Overview | The study and its versions; enter Build, UAT or Live from a version's row |
| Study Versions | Each version's lifecycle: cycles, sign-offs, go-live, amendments |
| Documents | The study's own documents: protocol, amendments, plans |
| Exports | Design exports of a frozen version |
| Audit Trail | The study's own events: versions, sign-offs, state |
| Study Team | Who holds a role on the study, one row for each person (a role is held in UAT and in Live together), with two more tabs, UAT Site Staff and Live Site Staff, for the people at each site of that workspace |
| Settings | Study details |
Build: the design of one version. Editable while the version is in Build; the same screens, read-only, afterwards.
| Menu item | What it is |
|---|---|
| Build | What the version holds and what stands between it and UAT |
| Forms | The version's case report forms |
| Visit Schedule | The protocol visits and their windows |
| Visit ⇄ Form Mapping | Which form is collected at which visit |
UAT and Live: the two workspaces. The same menu in both, against their own data; the design they run is shown read-only under Configuration.
| Menu item | What it is | Where |
|---|---|---|
| Dashboard | The version under test, or the released one | Both |
| Forms · Visit Schedule · Mapping | The design this workspace runs, read-only | Both |
| Sites · Participants · Casebook · Queries · AE Log · SAE Log | Operations | Both |
| Issues | What testers found in a cycle, and what became of it | UAT only |
| Results | How each cycle went: outcome, test data, issues, sign-offs | UAT only |
| SDV Plan · SDV Monitoring | Source data verification | Both |
| Exports | Data extracts | Both |
| Reports | This study's Enrollment, Site performance, Query aging, Visit compliance and Protocol deviations, in this workspace (and Lock readiness in Live): UAT's test data inside UAT, Live's inside Live, each page saying which | Both |
| E-Signatures | The signature register | Both |
| Site Team | Your own site's delegation log (site staff only) | Live only |
| Audit Trail | The workspace's own events | Both |
The exact permission behind each screen is listed in Screens and who sees them.
- Back to the portfolio.
Entering Build, UAT and Live
Entering Build, UAT or Live always asks first, from the Overview or from anywhere else. The 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 (the version is frozen, the UAT cycle is closed, the study is locked or completed, or your role holds nothing that changes data there). Entering UAT or Live starts a new session; moving from one to the other says that the data changes from test to real. If you have unsaved work that the move would lose, the question lists it and the button reads Discard changes and enter: nothing is carried across.
The door into an area is the version's row on the Overview: Open asks, then takes you in. A typed address or a link into UAT or Live opens the same dialog by itself. A workspace is somewhere you are only inside a study's UAT or Live area, so the coloured bar and the Live or UAT chip in the header (followed by as and your role) appear there and nowhere else. The chip tells you which workspace your session is in; it is not a switch. The Overview, Build, the Studies page and the rest of the platform belong to no workspace: going to one from UAT or Live leaves the workspace. A study's reports and E-Signatures show the figures of the workspace you are in, labelled UAT (test data) or Live (production); the Studies page's totals are Live's, and it says so.
Leaving a version's area for the Overview, the platform or another study, by a link or by the browser's Back button, asks too: Leave Live? (or UAT) names the study, the version and the cycle you are in and where you are going, with Stay in Live and Leave Live, so a stray click does not take you out. Moving between screens of the same area does not ask. Leaving a page with unsaved work asks differently: Leave with unsaved changes? lists what would be lost, with Keep editing and Discard changes and leave. If you move the session in a second tab, the first tab says so with a banner and a Reload button, and nothing it asks is read or written until you reload.
A closed UAT cycle
Open on a finished cycle's row shows that cycle as a read-only copy of the UAT workspace: its Dashboard, Participants (with each participant's casebook, queries and timeline), Casebook, Queries, Sites, Issues, Results and Audit Trail, with that cycle's test data. A banner on every screen says which cycle it is and how it ended, and nothing that adds, edits, closes or signs is on any of them. The audit trail is narrowed to the cycle's dates, and says so. The cycle still open is worked in the ordinary UAT workspace. The cycle's report page is in the row's ⋯ menu.
- Opens the cycle as a read-only copy.
- Every screen of a closed cycle carries this banner: which cycle, how it ended, and that nothing here can change.
- Why the cycle was closed, in the words the Project Manager gave.
- Who signed the version off: author, QA and approver.
- The trail is not kept for each cycle: this shows the workspace's events from the cycle's opening to its close.
Working inside a participant
From Participants, opening a participant gives you their own sidebar, in groups: Overview at the top, then Record (Visits & forms, AEs & medications), Work (Queries, Signatures, Deviations), Participant (Consent & eligibility, Details) and History (Activity, Reports). A coordinator or investigator starts from Record, a data manager from Work, an auditor from History. The Overview is kept short: Needs attention lists what is due, most urgent first, and each row goes straight to the place to act; a table of visits and a few key facts sit below. A visit whose window has passed with forms still open reads Overdue, with how many days late. Opening a visit lists the forms mapped to it; opening a form is where data entry happens.
Notifications
The bell in the top bar carries in-app notifications, and today it is deliberately quiet: Trialion raises one only when you are assigned a role on a study and when a study you created is created. It is not a task inbox and will not tell you that a query is ageing. Use Query aging and the SDV queue for that. Everything the system tells anyone is on Notifications and e-mails.
Test data and live data never mix
While you are in the UAT workspace everything you create is test data. When a version goes Live it starts a fresh production environment. Test participants, records and queries never appear in a Live view, and Live data never appears in a UAT view. The separation is enforced in the database, not only in the interface.