Revisions

Revisions are not just another view of the main document list. They represent document work that has been derived from or connected back to an existing record.

Who this is for

This page is for teams that need to evolve a document through a derived workflow while keeping the base record visible and governed.

What teams need to understand

• revisions are surfaced separately from the main documents list
• revisions help teams review document evolution without blurring the base record
• revisions still belong inside a governed, version-aware workflow

When to use a revision

Use a revision when:

• the team needs a derived path from an existing document
• the base document should remain distinct from in-progress revision work
• review participants need to understand how the new work relates to the source record

Use direct document editing when the change does not need that separate derived path.

Typical revision workflow

1. Start from an existing document.
2. Create or work from the revision path.
3. Update the derived content while preserving the relationship to the base record.
4. Review the revision in the context of the original document.
5. Move into approval if formal sign-off is needed.

Operational expectations

• A revision should remain visibly related to its source document.
• Revision work should stay separate from the main document list so teams can distinguish source content from derived work.
• Reviewers should be able to understand both the current revision content and the source record it came from.
• Teams should move from revision into approval when sign-off matters, rather than treating a revision alone as the final control point.

Key decisions

• when a team should work from a revision instead of editing the base document directly
• how revisions connect back to a document approval workflow
• how revision work fits into evidence and review preparation

Common mistakes to avoid

• treating revisions as just another name for document approvals
• editing the base record when the team really needs a separated derived path
• forgetting that revision work still belongs inside history-aware, review-aware governance

Acceptance checks

• A user can distinguish revision work from the main document library.
• A user can identify which base document a revision belongs to.
• A team can review revision content without losing visibility of the source record.
• A team can move from revision work into the approval workflow when formal sign-off is required.

Related pages

• Documents
• Document Approvals

API reference

Use TrialStack API reference for exact revision-listing and revision-related document contract details.