TrialStack logo
Browse docs
On this page

Artefacts

Trials

How TrialStack organizes trial-centric workflows across design, operations, review, and connected records.

Trials

Trials are the center of the TrialStack operating model. Most other records either support a trial directly or provide reusable context that can be linked back into a trial workflow.

Teams should think of the trial record as the operational spine of the workspace. It is where planning, oversight, supporting evidence, and connected entities come together.

Trial guide overview screenshot.

This screenshot is generated through the dedicated docs capture workflow so the page can reference a stable, reviewable asset instead of an ephemeral Playwright artifact.

Who this is for

This page is for teams responsible for setting up, maintaining, reviewing, or governing a trial record.

What trials are for

  • Capture and maintain the current trial record.
  • Connect supporting artefacts and operational entities.
  • Review history across regulated changes.
  • Coordinate protocol-facing work across multiple functions.

What a typical trial lifecycle looks like

  1. Create a trial record with the core identifying and planning information.
  2. Connect the trial to the organizations, sites, contacts, interventions, and systems that support execution.
  3. Add or link documents and evidence packs as the working record grows.
  4. Use the specialized trial workflow modules to maintain design, approval, monitoring, recruitment, retention, safety, and statistical detail.
  5. Review version history when a significant change needs to be understood, compared, or restored.
stateDiagram-v2
	[*] --> Draft
	Draft --> Configured: Link records and setup modules
	Configured --> Active: Trial operations underway
	Active --> Reviewed: Review history and comparisons
	Reviewed --> Restored: Restore prior version when needed
	Restored --> Active
	Reviewed --> Archived: Soft delete or archive under policy
	Archived --> Active: Undelete or restore

Core record operations

The product supports the main trial lifecycle operations customers expect from a governed record:

  • List and review trials.
  • Create a new trial.
  • Update the current trial state.
  • Clone an existing trial to accelerate setup.
  • Review change history and compare versions.
  • Restore an earlier version when a change needs to be rolled back.
  • Soft delete and restore a trial under policy control.
  • Link and review supporting media.

Treat cloning as an accelerator, not as a substitute for validating the resulting trial content.

What data users actually maintain on the trial form

The trial page is not a flat record with a handful of fields. It is a section-based governed form.

Users should expect the trial form to group data into:

  • overview data such as title, protocol number, study type, phase, therapeutic areas, and brief summary
  • indication data describing the conditions or diseases being studied
  • inclusion and exclusion criteria as structured repeatable criteria records
  • endpoint and objective sections that connect study goals to measurable outcomes
  • estimand content for ICH E9(R1)-style treatment effect definition
  • outcome-measure content used for registry-facing reporting
  • secondary identifier sections for trial numbers and related external identifiers

This matters for acceptance testing because the trial page should prove that study design data is structured, grouped, and reviewable rather than left as unstructured narrative.

When to use the main trial record

Use the main trial record when the team needs:

  • A single operational view of the study.
  • Access to connected records and supporting context.
  • History, comparison, restore, and review of major changes.
  • A launch point into the more specialized trial workflow modules.

Major workflow areas

TrialStack exposes dedicated workflows around the trial record, including:

These modules exist because some trial work needs its own cadence, ownership, and review depth.

Trials can be linked with:

Change control and review

Trial changes are not just point-in-time edits. The product supports history, comparison, restore, and controlled delete behavior because trial information often has downstream impact on oversight, approvals, reporting, and AI-assisted workflows.

Teams should be explicit internally about when to:

  • Make a normal update.
  • Compare versions before deciding on a change.
  • Restore a previous version.
  • Involve a quality or operational reviewer.

Acceptance checks for the trial form

  • A user can recognize the main trial sections instead of seeing a flat undifferentiated form.
  • A user can capture both simple overview data and repeatable structured records such as criteria or indications.
  • A reviewer can understand where protocol-facing data belongs on the page.
  • Trial edits remain compatible with history, comparison, and restore behavior.

When to use the trial page versus a trial workflow module

Use the main trial page when the team needs the overall record and its relationships.

Use a workflow module when the team is managing a specialized part of the trial lifecycle that has its own review and change history expectations.

Common mistakes to avoid

  • Treating the trial record as static setup data instead of a living governed record.
  • Cloning a trial and assuming the cloned content is ready without review.
  • Editing a sensitive area directly when compare or history review should happen first.
  • Splitting context across disconnected records instead of linking supporting entities back to the trial.

Trial workflow pages

API reference

Use TrialStack API reference for exact request and response details around listing, creating, updating, cloning, comparing, restoring, deleting, undeleting, and media-linking trial records.