> 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/visitors.md).
# Visitors
## Specs
| Label | Value |
| ------------------------- | ----------------------------- |
| **Version** | 2.0.0 (updated on 2024-06-10) |
| **Developer** | Labii Inc. |
| **Type** | Section |
| **Support Configuration** | No |
## Overview
The Visitors widget displays the access history of the current Labii record by listing the users who opened it and the timestamps of those visits. Labii captures visitor entries automatically in the background, making the widget useful for transparency, oversight, and regulated record review where teams need to know who accessed a document in addition to who changed it. This provides a lightweight access audit trail that complements edit history and version history without requiring users to maintain a separate manual log. It presents the same core visitor information as the [Visitors](/user-guide/detail-view/visitors.md) tab in the record detail view, but keeps that visibility inside the record itself.
## Use Cases
* **Access auditing**: Review who opened a record during a protocol, experiment, or quality workflow.
* **Compliance review**: Demonstrate that access history is being tracked for controlled records.
* **Collaboration visibility**: Confirm whether team members, reviewers, or approvers have viewed a record.
* **Investigation support**: Check who accessed a record when investigating process deviations, data review timing, or unexpected workflow outcomes.
* **Operational transparency**: Distinguish between users who merely viewed a record and users who actually changed it in the Activities log.
## Interface
### Read-only View
In read-only view, the widget displays a list of visitor entries for the current record. Each entry identifies the user who viewed the record and when the visit occurred. The list serves as a straightforward access history rather than an editable annotation or collaboration tool.
* **Visitor List**: Shows the users who accessed the record.
* **Timestamp Visibility**: Displays when each visit occurred.
* **Access Context**: Helps reviewers understand record readership separately from edit activity.
* **Audit Support**: Keeps access history visible inside the same record being reviewed.
The read-only view lists record visitors and the timestamps of their access events
### Edit View
The Visitors widget does not provide direct editing of visitor records. In practice, it remains read-only because visit events are created automatically by Labii whenever a record is opened. Users can review the visitor list, search it, or filter it, but they cannot manually add, change, or delete visit history from the widget.
* **Input Methods**: No manual data entry is supported.
* **Formatting Options**: No content formatting is available because visitor entries are system-generated.
* **Validation**: Visitor records are captured automatically rather than entered by users.
* **Collaboration**: Multiple users can review the same access history while the visit records remain protected from direct modification.
{% hint style="info" %}
The Visitors widget captures access history automatically. Adding the widget to a record makes the log visible, but it does not control whether visitor events are recorded.
{% endhint %}
## Configuration
The Visitors widget does not require or support widget-specific configuration. After adding it to a record, it automatically displays the visitor history for that current record.
### Initial Setup
{% stepper %}
{% step %}
Open the target record and add the **Visitors** widget to a section.
{% endstep %}
{% step %}
Save the section. The widget immediately loads the visitor history for the current record.
{% endstep %}
{% step %}
Use the list to review who accessed the record and when those visits occurred.
{% endstep %}
{% endstepper %}
### Required Settings
The Visitors widget has no required settings.
### Optional Settings
The Visitors widget has no optional settings.
## Additional Functions
### Search Visitors
Users can search the visitor list by keyword to find specific visitor entries more quickly when working with the same interface pattern as the detail-view Visitors page.
### Filter Visitors
The visitor interface can be filtered to narrow the visible list, such as displaying all visitors or only the current user's visitor entries.
### Access Review Context
The widget helps distinguish viewing history from change history, making it useful in workflows where simply opening a record is significant even if no edit occurred.
## Best Practices
### Data Organization
* Place the Visitors widget on records where access visibility matters, such as quality records, approved protocols, controlled forms, or sensitive experimental reports.
* Keep it near Activities or Versions when reviewers need a fuller audit picture that includes both access and change history.
* Use the widget on records involved in multi-user review workflows so teams can confirm whether readers actually opened the document.
### Performance Optimization
* Use search or filter tools when reviewing large visitor histories instead of scanning the entire list manually.
* Keep the widget on records where access tracking adds value rather than adding it broadly to every low-risk record.
* Use the widget as a focused access log, not as a replacement for the richer audit-trail tools that track edits or historical record states.
### Security and Compliance
* Treat visitor history as supporting access evidence, especially in controlled workflows where record readership matters.
* Use the widget together with Activities and Versions when a workflow requires both access and change traceability.
* Avoid relying on memory or informal communication to confirm record review when visitor logs are available.
{% hint style="success" %}
The Visitors widget is most useful in review-heavy or regulated workflows where it matters not only who changed a record, but also who accessed it.
{% endhint %}
### Common Pitfalls to Avoid
* **Avoid** using the Visitors widget as proof that a user approved or understood the content; it only shows access, not intent or signoff.
* **Avoid** confusing visitor history with change history; use Activities when you need to know what was modified.
* **Instead** combine visitor, activity, and version records when a complete audit narrative is required.
### Maintenance and Troubleshooting
* If expected access entries seem missing, confirm that you are reviewing the correct record rather than a related one.
* If the list becomes long, use search or filter tools before manually scanning every visitor entry.
* If you need proof of action rather than access, pair the widget with Signers or Activities instead of relying on Visitors alone.
### Workflow Integration Tips
* Combine the Visitors widget with [Activities](/widgets/section-widgets/regulation/audit-trail/activities.md) to distinguish viewing from editing.
* Use it with [Versions](/widgets/section-widgets/regulation/audit-trail/versions.md) when review workflows need both access history and saved historical states.
* Pair it with [Signers](/widgets/section-widgets/regulation/signature/signers.md) when teams need to compare who viewed a record versus who formally signed it.
## Related Widgets
* [**Activities**](/widgets/section-widgets/regulation/audit-trail/activities.md): Shows who changed a record and what changed, complementing the read/access history shown by Visitors.
* [**Versions**](/widgets/section-widgets/regulation/audit-trail/versions.md): Displays historical record snapshots that complement visitor access logs.
* [**Activities**](/widgets/section-widgets/regulation/audit-trail/activities.md): Choose Activities when the key question is what changed rather than who viewed the record.
* [**Signers**](/widgets/section-widgets/regulation/signature/signers.md): Choose Signers when you need intentional approval or rejection actions rather than passive access records.
---
# 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, and the optional `goal` query parameter:
```
GET https://docs.labii.com/widgets/section-widgets/regulation/audit-trail/visitors.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.