Entity Views And Forms

Most TrialStack record pages are built from the same underlying model. Trials, organizations, sites, contacts, interventions, media, templates, rules, and several other records all use the same pattern for route binding, page layout, section grouping, and field rendering.

That matters because customers do not need to relearn the UI for every record type. Once a team understands how one governed entity page behaves, most of the rest of the product feels familiar.

The shared page model

Most entity pages follow the same four-part structure.

1. A binding decides which entity is being shown, how the route loads it, how history is fetched, and how the page title and breadcrumbs are built.
2. A shared detail page renders the entity shell, summary behavior, history access, and tab layout.
3. Form metadata defines the sections, field labels, field descriptions, layout spans, and control types for the entity.
4. A shared field renderer turns that metadata into the actual controls users see on screen.

In practice, this means the product is not hand-assembling each record page from scratch. Most record pages differ because the metadata differs, not because the whole UI stack changes.

What users see repeatedly

Across most entity pages, users should expect the same recurring building blocks.

• Section-based forms with stable headings and descriptions.
• Inline field descriptions that explain business meaning, not just UI hints.
• Consistent control types for the same kind of data.
• History-aware editing, comparison, and restore patterns for governed records.
• Linked-record context, such as organizations, sites, contacts, interventions, or media.

Common field types across the product

The shared renderer supports a common field vocabulary. Customers will repeatedly see:

• text, email, phone, fax, and URL inputs for core identity and contact data
• select and multi-select controls for classifications, statuses, and reusable vocabularies
• rich text and textarea controls for narrative summaries and governed descriptive content
• address autocomplete and address fields for location-aware records
• number, date, and datetime fields for measurable or time-based attributes
• tags, switches, and booleans for lightweight classification and toggle state
• array-table sections for repeatable structured data such as criteria, identifiers, accreditations, or qualifications
• combobox-style entity selectors where the user is linking one record to another

These control types should behave consistently across entities. A team that learns how one array-table section works should recognize the same behavior in another entity.

Why field descriptions matter

The explanatory text below a field is part of the product contract.

Those descriptions tell users what the field represents, what kind of value belongs there, and how that value is used operationally. In acceptance testing terms, a field description should support these checks:

• A user can tell what the field means without leaving the page.
• A user can distinguish similar fields, such as legal name versus operating name or protocol number versus secondary identifiers.
• A reviewer can understand why a field exists and what kind of decision it supports.

Common section patterns by entity type

Most entities use a small number of recurring section patterns.

Trials

Trial pages are the deepest example of the model. The form is grouped into sections such as overview, indications, inclusion criteria, exclusion criteria, endpoints, objectives, estimands, outcome measures, and secondary identifiers.

Users should expect both simple fields and structured repeatable sections. Trial data is not just header information. It includes study design content, eligibility logic, outcome definitions, and registry-facing identifiers.

Organizations and sites

Organization pages usually separate business information, profile, identifiers, address, contact, and accreditations.

Site pages usually separate identity, contact, location, capacity, and capabilities.

This split is deliberate. Organization data describes the higher-level operating entity. Site data describes a specific execution location with its own capacity and local context.

Contacts

Contact pages are much richer than a basic address book. The form can include details, location, identifiers, education, experience, licenses, certifications, memberships, and training.

Users should treat contacts as governed stakeholder records, not as a lightweight list of names.

Interventions

Intervention pages usually divide data into basics, identifiers, regulatory classification, scientific characteristics, procedure details, behavioral details, storage, and handling.

That structure matters because intervention records often support both scientific review and operational execution.

Media

Media pages are simpler but still follow the same model. The form usually splits into information and analysis results, with fields for display name, original filename, media type, category, detected file type, size, description, and tags.

Users should understand media as a governed supporting record, not just an upload bucket.

How to use this in acceptance testing

When a team writes acceptance tests for a record page, the tests should validate both workflow and form structure.

• The page should load through the correct route and show the right entity context.
• The expected sections should be visible for that entity type.
• Each section should group the correct class of data.
• Fields should render with the control type that matches their data semantics.
• Inline descriptions should explain the field well enough for a user to understand what belongs there.
• Changes should follow the governed history, compare, and restore model where that entity supports it.

Acceptance checks

• A user can move between different entity pages without relearning the basic form model.
• A user can identify the section structure for a record and understand what kind of data belongs in each section.
• A user can understand the meaning of a field from its label and inline description.
• A user sees the same control behavior for the same kind of data across different entity pages.
• A reviewer can use the page structure itself as evidence of what data the product expects for that record type.

Read next

• Platform overview
• Trials
• Organizations And Sites
• Contacts

API reference

Use TrialStack API reference for exact entity contracts. Use this page to understand the shared page and field model those contracts surface in the UI.