> For the complete documentation index, see [llms.txt](https://docs.labii.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.labii.com/widgets/section-widgets/regulation/audit-trail/versions.md).
# Versions
## Specs
| Label | Value |
| ------------------------- | ----------------------------- |
| **Version** | 3.0.0 (updated on 2024-06-10) |
| **Developer** | Labii Inc. |
| **Type** | Section |
| **Support Configuration** | No |
## Overview
The Versions widget displays the saved version history of a Labii record directly inside a section, allowing users to review prior states, inspect version metadata, and restore earlier revisions when needed. Labii automatically creates a new version whenever changes are made, preserving the progression of the record over time without requiring manual snapshot creation. Each version entry includes a version number, commit message, user, timestamp, and blockchain-style hash key that helps demonstrate version integrity. The widget shares the same core version content as the [Versions](/user-guide/detail-view/versions.md) tab in the record detail view, but keeps version history visible alongside the record itself.
## Use Cases
* **Change review**: Examine how a record evolved over time without leaving the section view.
* **Version rollback**: Restore a previous record state after an incorrect edit or unwanted change.
* **Audit support**: Present a defensible version history with timestamps, user attribution, and immutable hash references.
* **Commit note management**: Rename commit messages to make important milestones easier to recognize later.
* **Regulated documentation**: Verify that historical record states remain preserved and traceable throughout a controlled workflow.
## Interface
### Read-only View
In read-only view, the widget displays a list of versions for the current record. Each row includes the version number, a commit message link, the user who created the version, a timestamp, a cryptographic hash key, and a restore action. A verification-style icon appears next to the hash to reinforce the integrity-focused design.
* **Version List**: Shows versions in a chronological history view for the record.
* **Commit Visibility**: Displays either auto-generated or user-edited commit messages that summarize the change.
* **Integrity Metadata**: Includes a unique hash key for each version.
* **Recovery Access**: Provides a direct restore action for each saved version.
The read-only view lists saved versions with commit details, integrity hashes, and restore actions
The detail view typically loads the most recent versions first, and older items can be loaded as needed.
### Edit View
The Versions widget does not support direct editing of version contents. In practice, its interactive behavior is limited to reviewing version details, updating commit messages, previewing versions in read-only mode, and restoring earlier states. Version records themselves are system-generated and preserved automatically.
* **Input Methods**: Edit commit messages through the version entry controls when a clearer label is needed.
* **Formatting Options**: No document formatting is available because versions are generated from record changes rather than manual section content.
* **Validation**: Restoring a version creates a new version entry instead of modifying historical versions in place.
* **Collaboration**: Multiple users can review the same version history while historical entries remain protected from direct overwrite.
{% hint style="info" %}
Labii creates versions automatically when changes are made, so users do not need to manually save checkpoints for routine record history.
{% endhint %}
## Configuration
The Versions widget does not require or support widget-specific configuration. After adding it to a record, it automatically displays the version history for that current record.
### Initial Setup
{% stepper %}
{% step %}
Open the target record and add the **Versions** widget to a section.
{% endstep %}
{% step %}
Save the section. The widget immediately loads the existing version history for the current record.
{% endstep %}
{% step %}
Use the version list to review prior states, rename commit messages, preview saved versions, or restore an earlier revision when needed.
{% endstep %}
{% endstepper %}
### Required Settings
The Versions widget has no required settings.
### Optional Settings
The Versions widget has no optional settings.
{% hint style="warning" %}
Restoring a previous version does not delete later history. Instead, Labii creates a new version documenting the restore action.
{% endhint %}
## Additional Functions
### Preview a Version
Click a version's commit message to open that historical state in a read-only preview that uses the same general presentation style as print view.
### Update a Commit Message
Use the edit control next to a version entry to replace the default or existing commit message with a clearer note. This is useful when marking a milestone, clarification, or intentional revision point.
{% hint style="info" %}
Editing the commit message does not change the underlying version content or its hash-linked integrity.
{% endhint %}
### Restore a Previous Version
Click **Restore to Version X** to bring the record back to the selected historical state. Labii records that action by creating a new version entry noting the restore event.
### Search and Filter Versions
When using the same interface pattern as the detail-view Versions page, users can search the version list by keyword and filter it to views such as all versions, renamed versions, or versions created by the current user.
### Integrity Hash Review
Each version includes a unique hash key designed to help verify that the historical record has not been altered. This supports traceability and defensibility in regulated workflows.
## Best Practices
### Data Organization
* Update commit messages for major milestones so important versions are easier to identify later.
* Use the widget on records where revision traceability matters, such as protocols, approved experiments, quality events, and controlled forms.
* Keep version review close to signatures or audit sections when users need to assess change history before approval decisions.
### Performance Optimization
* Use search and filter tools to narrow the list when a record has many versions.
* Open historical previews only for the versions relevant to the review at hand instead of scanning every entry manually.
* Reserve restore actions for intentional rollback events rather than routine navigation through historical content.
### Security and Compliance
* Treat hash keys and preserved version history as compliance-supporting evidence rather than editable notes.
* Use restore actions carefully, because they create new history and may affect downstream review workflows.
* Rely on the immutable historical chain instead of maintaining unofficial duplicate copies of prior record states.
{% hint style="success" %}
The Versions widget is especially effective when paired with approval and audit-trail sections, because it provides both change preservation and recovery options inside the same record.
{% endhint %}
### Common Pitfalls to Avoid
* **Avoid** assuming a restored version erases later history; Labii preserves the full sequence and adds a new restore version.
* **Avoid** leaving all commit messages in their default form when the record contains major milestones that future reviewers need to find quickly.
* **Instead** rename key versions and use preview before restoring when you need to confirm the exact historical state.
### Maintenance and Troubleshooting
* If you cannot find the expected historical state, load more versions or use search/filter controls before concluding it is missing.
* If a version label is unclear, edit the commit message to make future review easier.
* If you need a full historical review for regulated inspection, combine version history with the Activities widget to see both snapshots and event-level changes.
### Workflow Integration Tips
* Combine the Versions widget with [Activities](/widgets/section-widgets/regulation/audit-trail/activities.md) to review both saved checkpoints and individual change events.
* Use it with [Signers](/widgets/section-widgets/regulation/signature/signers.md) when approved records may require later review of pre-sign or post-rejection states.
* Pair it with [Visitors](/widgets/section-widgets/regulation/audit-trail/visitors.md) when audit workflows require both historical record states and access history.
## Related Widgets
* [**Activities**](/widgets/section-widgets/regulation/audit-trail/activities.md): Shows event-by-event record changes that complement the checkpoint-style history provided by Versions.
* [**Visitors**](/widgets/section-widgets/regulation/audit-trail/visitors.md): Displays access history, which complements version history when review workflows need both change and view evidence.
* [**Signers**](/widgets/section-widgets/regulation/signature/signers.md): Adds controlled approval workflows that often depend on version review before or after signoff.
* [**Visitors**](/widgets/section-widgets/regulation/audit-trail/visitors.md): Choose Visitors when the key question is who accessed the record rather than how the content changed over time.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.labii.com/widgets/section-widgets/regulation/audit-trail/versions.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.