How to Track Changes and Comments in a Shared Reference Library
By Dr. Zubair Khalid, DVM, MS, PhD ·

Quick Answer
- Use tags, notes, and custom fields in Zotero or Mendeley to create a lightweight review system for shared references, since neither tool has a built-in track-changes feature.
- Set up a standardized "review status" tag (for example, Pending, In Review, Approved, Rejected) and require team members to add dated comments in the note field for every status change.
- This system works well for small teams but lacks version history and attribution controls, so you must establish clear naming conventions and audit rules before sharing your library.
Why Reference Managers Lack Track Changes
Reference management software like Zotero and Mendeley were designed to store, organize, and cite bibliographic information. They were not built as collaborative document editing platforms. The core architecture of these tools prioritizes metadata consistency, citation formatting, and library synchronization across devices. When you share a library with a supervisor or team member, the software gives everyone access to the same records, but it does not provide the redline markup, comment threads, or version comparison that you find in word processors.
This creates a practical problem for research teams. A supervisor needs to mark a reference as relevant or irrelevant. A lab mate needs to add a note about a methodological flaw. A collaborator needs to flag a citation for follow-up. Without a track-changes feature, these feedback loops break down. People resort to email chains, separate documents, or verbal conversations, and the feedback becomes disconnected from the reference itself.
The solution is to build a structured review system using the features that reference managers do provide. Tags, notes, and custom fields are available in both Zotero and Mendeley. When you combine these features with a clear protocol, you create a functional feedback loop that lives inside the shared library. This approach does not replicate every function of track changes, but it does solve the core problem of capturing and organizing feedback on references.
Core Principles of a Shared Review System
Standardization Before Collaboration
The most common reason shared reference libraries fail is the lack of standardization. If one person uses a tag called "Needs Review" and another uses "To Read," the feedback becomes impossible to filter. Before you invite anyone to your library, you must define the vocabulary that everyone will use. This includes the exact tag names, the note format, and the meaning of each status.
A review status tag is the backbone of the system. Choose a small set of statuses that cover the full review cycle. A practical set includes Pending, In Review, Approved, and Rejected. You may also want a separate tag for "Needs Revision" if your team frequently asks for changes. Keep the list short. Every additional tag increases the chance of inconsistent use.
The note field is where the actual feedback lives. You need a consistent format so that reviewers know where to write and where to read. A simple structure works best. Start with the date, then the reviewer name, then the comment. For example, "2025-06-14, Dr. Chen, this paper is relevant to our methods section but the sample size is small." This format creates a chronological record within each reference.
Attribution and Accountability
In a shared library, you need to know who said what and when. The note format above handles this manually. Each reviewer writes their name and the date at the start of their comment. This is not as robust as the automatic attribution you get in a word processor, but it is sufficient for most research teams.
The Committee on Publication Ethics Core Practices emphasize the importance of transparency and accountability in research processes. While these practices focus on publication ethics, the same principles apply to internal review workflows. When every comment is attributed to a named person with a date, the team can trace decisions and understand the basis for each reference being included or excluded.
Synchronization and Conflict Management
Zotero and Mendeley both offer library synchronization across devices and users. When multiple people edit the same library, conflicts can occur. Zotero handles this by creating conflicting versions of an item when two users edit it simultaneously. You need a protocol for resolving these conflicts. The simplest approach is to designate one person as the library administrator who resolves conflicts and merges duplicate records.
At a Glance
| Feature | Zotero | Mendeley |
|---|---|---|
| Tag color coding | Yes, assign colors for visual scanning | No, rely on exact tag names |
| Sidebar tag filter | Yes, click a tag to view all items | No, use search function |
| Multiple notes per reference | Yes, add unlimited notes | Yes, but less flexible |
| Custom fields | Yes, via extra fields | Limited, fewer options |
| Conflict handling | Creates conflict versions | Less transparent, manual merge |
Setting Up a Review Status Tag System in Zotero
Zotero provides a flexible tagging system that works well for review workflows. Tags are searchable, color-coded, and can be assigned to multiple items at once. This makes them ideal for marking review status across a large library.
Step 1: Create the Tag Set
Open your Zotero library and navigate to the Tags pane. Create the following tags: Pending, In Review, Approved, Rejected, and Needs Revision. Assign a color to each tag so that you can visually scan your library and see the status of each reference. For example, use gray for Pending, yellow for In Review, green for Approved, and red for Rejected.
Step 2: Assign Initial Status
When you add a new reference to the library, assign the Pending tag by default. This ensures that every item has a status from the moment it enters the library. Without a default status, items can slip through the review process without anyone noticing.
Step 3: Use the Notes Field for Feedback
Each reference in Zotero has a Notes tab where you can add multiple notes. Instruct your team to add a new note for each review comment instead of editing an existing note. This preserves the history of feedback. Each note should start with the date and the reviewer name, followed by the comment.
Step 4: Filter by Status
Use the tag filter in the left sidebar to view all items with a specific status. For example, click the "In Review" tag to see everything that is currently being evaluated. This gives you a working queue for the team. You can also create saved searches that combine tags with other criteria, such as a specific collection or a date range.
Setting Up a Review System in Mendeley
Mendeley offers a similar set of features, but the implementation differs slightly. Mendeley uses tags and notes, but it does not have the same color-coding options as Zotero. The review system still works, but you need to rely more on the tag names and the note format.
Step 1: Create Tags in Mendeley
In Mendeley, you can add tags to a reference by selecting the item and typing in the Tags field. Create the same set of tags you would use in Zotero: Pending, In Review, Reviewed, Rejected, and Needs Review. Mendeley does not support color coding for tags, so you must be disciplined about using the exact tag names.
Step 2: Use the Notes Field
Mendeley has a Notes field for each reference. The same protocol applies. Add a new note for each review comment, starting with the date and reviewer name. Mendeley also allows you to add files to a reference, which can be useful for attaching a review checklist or a comment document.
Step 3: Filter by Tag
Mendeley allows you to filter your library by tag using the search function. Type the tag name into the search box, and Mendeley will show all items with that tag. This is less convenient than Zotero's sidebar filter, but it still provides a way to view all items in a particular review state.
Using Custom Fields for Structured Feedback
Both Zotero and Mendeley allow you to add custom fields to references. These fields can be used to capture structured information that does not fit into the standard bibliographic fields. For example, you can create a custom field called "Reviewer Decision" with values like "Include" or "Exclude." You can also create a field called "Priority" with values like "High," "Medium," or "Low."
Custom fields are useful when you need to sort or filter on a specific attribute. For example, if you want to see all references that a supervisor has marked as "High Priority," you can sort by that custom field. This is more reliable than relying on tags, which can be applied inconsistently.
Limitations of Custom Fields
Custom fields have limitations. They are not always visible in the main library view, and they may not be included in the citation output. You need to decide whether the structured data is worth the extra effort. For most teams, tags and notes are sufficient. Custom fields are best used when you need to generate reports or when you have a large library that requires systematic filtering.
The Review Workflow
A structured review workflow ensures that every reference moves through the same process. This consistency is what makes the system work. Without a defined workflow, team members will use the tags and notes inconsistently, and the library will become disorganized.
Step 1: Submission
A team member adds a new reference to the library and assigns the "Pending" tag. The member also adds a note explaining why the reference is being submitted and what section of the project it relates to.
Step 2: Initial Screening
A designated reviewer, often the supervisor or a senior team member, reviews the pending items. The reviewer reads the note and the abstract, then assigns a status. If the reference is relevant, the reviewer changes the tag to "In Review" and adds a note with their initial assessment. If the reference is not relevant, the reviewer changes the tag to "Rejected" and adds a note explaining why.
Step 3: Detailed Evaluation
For items that pass the initial screening, a detailed evaluation is performed. The reviewer reads the full text and assesses the quality, relevance, and methodological rigor. The reviewer adds a note with their detailed comments. The tag remains "In Review" until the evaluation is complete.
Step 4: Final Decision
The reviewer makes a final decision and changes the tag to "Approved" or "Rejected." The note should include the rationale for the decision. If the reference needs revision, the tag is changed to "Needs Revision" and the note explains what changes are required.
Step 5: Periodic Review
The team should periodically review the library to ensure that all items have a status. Items with no tag should be flagged and assigned a status. This prevents the library from accumulating unprocessed references.
Common Failure Patterns
Even with a clear system, teams often encounter problems. Understanding these failure patterns can help you avoid them.
Inconsistent Tag Use
The most common failure is inconsistent tag use. One person uses "In Review" while another uses "Reviewing." One person tags an item as "Approved" while another uses "Accepted." This makes the tag filter useless. The solution is to document the tag vocabulary and enforce it during the review process.
Notes Without Attribution
Another common failure is notes without attribution. A reviewer adds a comment but does not include their name or the date. This makes it impossible to know who made the comment or when. The solution is to require the date and name at the start of every note.
Editing Notes Instead of Adding New Ones
When a reviewer edits an existing note instead of adding a new one, the history of the review is lost. The team cannot see how the assessment changed over time. The solution is to instruct the team to add a new note for each comment and never edit an existing note.
Ignoring the Status Tags
Some teams create the tags but then ignore them. They add references to the library without assigning a status, and the library becomes a collection of unprocessed items. The solution is to make the status assignment a mandatory step in the workflow.
Conflict Resolution Failures
When two people edit the same reference simultaneously, Zotero creates a conflict. If the team does not have a protocol for resolving conflicts, the library can become corrupted or the feedback can be lost. The solution is to designate one person as the conflict resolver and to document the resolution process.
Records and Measurements
A shared reference library is a record of the team's research process. The tags and notes you create are a form of documentation. This documentation is valuable for several reasons.
Audit Trail
The notes provide an audit trail of the review process. You can see who reviewed each reference, when they reviewed it, and what they said. This is useful for accountability and for understanding the basis of the final reference list.
Reproducibility
The review process is part of the research methodology. If you document the review process, you can reproduce it or explain it to others. This is consistent with the principles of transparent research reporting promoted by the EQUATOR Network. The EQUATOR Network provides reporting guidelines for health research, and the same principles of transparency apply to the reference review process.
Data Management
The NIH Data Management and Sharing Policy emphasizes the importance of planning for data management and sharing. A shared reference library is a form of research data. The review notes and status tags are part of the data that should be managed and preserved. You should consider how the library will be archived and whether the review notes need to be preserved for the project duration.
Limitations of the Tag and Note System
The tag and note system is a workaround, not a replacement for track changes. It has several limitations that you should understand before implementing it.
No Version History
The system does not provide version history. If a reviewer changes a tag from "In Review" to "Approved," you cannot see the previous state unless you have a note that records the change. The note protocol helps, but it is not automatic.
No Automatic Attribution
The system relies on manual attribution. If a reviewer forgets to add their name to a note, the comment becomes anonymous. This is a risk in a shared library.
No Conflict Detection
The system does not detect conflicts between reviewers. If two reviewers disagree on the status of a reference, the system does not flag the disagreement. The team must manually identify and resolve disagreements.
No Notification System
The system does not notify team members when a reference changes status. A reviewer may change a tag, but the team member who submitted the reference will not be notified. The team must check the library regularly to see the updated status.
Professional Escalation Criteria
The tag and note system works for small teams with a clear protocol. It may not be sufficient for larger teams or for projects with complex review requirements. You should consider a more robust solution if you encounter any of the following situations.
Large Team Size
If your team has more than 10 members, the manual system becomes difficult to manage. The risk of inconsistent tag use and lost notes increases with the number of reviewers. You may need a more structured tool or a dedicated review platform.
Complex Review Requirements
If your review process requires multiple rounds of review, formal sign-offs, or detailed scoring, the tag and note system may not be sufficient. You may need a tool that supports structured review forms and automated workflows.
Regulatory or Compliance Requirements
If your research is subject to regulatory or compliance requirements, you may need a system that provides a complete audit trail. The tag and note system may not meet these requirements. You should consult with your institution or sponsor to determine the required level of documentation.
Need for Formal Version Control
If you need to track every change to a reference record, the tag and note system is not sufficient. You need a system with version control, such as a document management system or a version control tool.
Safety and Regulatory Context
The reference review process is part of the research workflow. It is not a regulated activity in itself, but it is subject to the broader requirements of research integrity and data management.
Research Integrity
The Committee on Publication Ethics Core Practices emphasize the importance of transparency and accountability in research. The review process is part of this. When you document the review process, you are supporting the integrity of the research.
Data Management
The NIH Data Management and Sharing Policy requires researchers to plan for data management and sharing. A shared reference library is part of the research data. You should consider how the library will be stored, preserved, and shared in accordance with the policy.
Institutional Policies
Your institution may have specific policies regarding the use of reference management software and the sharing of research data. You should consult your institution's policies before implementing a shared library.
Frequently Asked Questions
Can I use the same tag system in both Zotero and Mendeley?
Yes, the tag system works in both tools. The tag names are the same, but the implementation differs. Zotero supports color-coded tags and a sidebar filter. Mendeley requires you to use the search function to filter by tag. The note format is the same in both tools.
How do I handle a conflict when two reviewers edit the same reference?
Zotero creates a conflict version when two people edit the same item simultaneously. You need a protocol for resolving conflicts. The simplest approach is to designate one person as the conflict resolver. That person reviews the conflicting versions, merges the changes, and deletes the duplicate.
What should I do if a team member forgets to add a note?
The note is the primary record of the review. If a team member forgets to add a note, the review is not documented. You should ask the team member to add the note as soon as possible. If the team member is unavailable, you should add a note yourself, documenting the date and the fact that the review was not documented.
Can I use custom fields instead of tags?
Yes. Custom fields can be used to store structured data such as review status or priority. Custom fields are useful when you need to sort or filter by a specific value. However, tags are easier to apply and more visible in the library view. Most teams use tags for status and custom fields for additional data.
How do I export the review notes for a report?
Zotero and Mendeley both allow you to export references and notes. You can export the library as a file and include the notes in the export. The exact export format depends on the tool and the citation style you choose. You can also copy the notes manually if you need to include them in a report.
What happens if I delete a tag?
If you delete a tag, the tag is removed from all items that have it. The notes are not affected. If you delete a tag by mistake, you will need to reapply the tag to the affected items. This is why it is important to document the tag vocabulary and to be careful when managing tags.
Can I share the library with someone who does not have Zotero or Mendeley?
No. The library is stored in the reference manager. To access the library, the person must have the same reference manager installed. You can export the library as a file and share the file, but the person will need the software to open it.
How often should I review the library?
The review frequency depends on the project timeline. For an active project, you should review the library at least once a week. This ensures that the status tags are up to date and that no references are stuck in the review process. For a less active project, a monthly review may be sufficient.
Using the Evidence
| Source | Best use in this topic | Important limitation |
|---|---|---|
| Research Methods Resources | official guidance | Check the linked page for current local requirements |
| EQUATOR Network | official guidance | Check the linked page for current local requirements |
| Core Practices | official guidance | Check the linked page for current local requirements |
Related Articles
- Reference Managers for Researchers: Choosing a Workflow That Survives Collaboration
- Genomic Library
- Biology Notes
- Ncbi Reference Genome
- Two Notes Genome
References and Further Reading
- Research Methods Resources. National Library of Medicine.
- EQUATOR Network. EQUATOR Network.
- Core Practices. Committee on Publication Ethics.
- NIH Grants and Funding. National Institutes of Health.
- ORCID for Researchers. ORCID.
- Data Management and Sharing Policy. National Institutes of Health.
- NCBI Literature Resources. National Center for Biotechnology Information.
- PubMed. National Library of Medicine.
This article is educational and does not replace institutional policy, professional advice, or applicable safety and regulatory requirements.