Written and maintained by CASRAI Editorial Board
Last updated
Zotero is not a screening tool, but it is a capable place to assemble and de-duplicate a systematic review’s search results — and if you set it up correctly it also produces most of the numbers your PRISMA flow diagram needs, as a by-product of the structure rather than a separate counting exercise.
Set it up incorrectly and you will lose exclusion data at the de-duplication step without noticing.
Structure: one library, one collection per database
The recommended shape is a new group library for each review, with each set of search results imported into its own collection.
That is not organisational tidiness. The number of items in each collection is the number of records returned by that database search — the “records identified” figures at the top of a PRISMA diagram. Import everything into one collection and you have thrown that away, and will end up reconstructing it later from search logs.
A group library rather than a personal one also gives you co-reviewers, which matters for the dual-screening a review requires.
Collections behave like playlists, not folders
An item can belong to several collections at once, and adding an item to another collection does not duplicate it. Zotero’s own documentation makes the analogy: collections are more like music playlists than filesystem folders.
This is what makes a stage-based structure workable. A record can sit in “Embase results” and simultaneously in “full-text review” without being copied, so the provenance of every record survives all the way through screening.
De-duplication: merge, never delete
This is the one step where a careless click destroys data.
Zotero’s Duplicate Items special collection surfaces items it believes are duplicates. The rule for resolving them is unambiguous: always merge, never delete one of the pair.
The reason is that a merge retains all the collections and tags of the merged items, and deleting one loses them. In a review, those collections and tags are your data — which database a record came from, which reviewer excluded it, and why. Delete the wrong copy of a duplicate and you have silently removed a record from one database’s count while keeping the other, corrupting the flow diagram in a way that is very hard to detect afterwards.
Note also that Zotero will not auto-merge for you. Detection is automatic; resolution is manual. That is a limitation for large sets, and it is the point at which purpose-built screening tools become worth their cost.
Tags for screening status and exclusion reasons
Coloured tags can mark processing status — rejected, unavailable, and so on — and a useful convention is to prefix exclusion-reason tags with a character such as * so they group together.
The payoff is the same as with collections: the count of items carrying each tag is the count for that exclusion criterion, which is exactly what PRISMA asks you to report. Tagging as you screen means the numbers are already there at the end.
Where Zotero stops being the right tool
Be realistic about the boundary.
- Large libraries. Zotero slows down more than some alternatives with very large databases — beyond roughly 30,000 entries. Big reviews will feel it.
- No automated merging, so de-duplicating tens of thousands of records is manual work.
- No blinded dual screening. Zotero has no concept of two reviewers independently screening the same record without seeing each other’s decisions, and no built-in conflict resolution. That is the core function of a screening platform.
A reasonable division of labour: Zotero to assemble, de-duplicate and hold the corpus with full provenance; a dedicated tool such as Covidence for blinded screening and conflict resolution once the record set is clean.
A workable sequence
- Create a group library for the review.
- Import each database’s results into its own collection; record the counts before doing anything else.
- Run Duplicate Items and merge every pair. Never delete.
- Record the post-deduplication total — the “records screened” figure.
- Screen with coloured tags for status and
*-prefixed tags for exclusion reasons. - Read tag counts straight off for the exclusion breakdown.
Related
The screening stage itself — what two reviewers should be doing with those records — is covered in title and abstract screening, and note that inter-rater agreement on a screening task is exactly where the prevalence problem in Cohen’s kappa shows up, because the include category is usually rare.
Frequently asked questions
Should I use one collection or several?
One per database search. The collection counts are your PRISMA “records identified” figures, and merging the imports together destroys them.
Does adding an item to two collections duplicate it?
No. Collections behave like playlists; an item can be in many at once and there is still only one item.
Why must I merge duplicates instead of deleting one?
Because merging retains the collections and tags of both items, and deleting loses them. In a review those are your provenance and exclusion data.
Can Zotero merge duplicates automatically?
No. It detects them; you resolve them by hand. For very large sets this is the main practical limitation.
How large a library can Zotero handle?
It slows relative to some alternatives past roughly 30,000 entries. That is usually the point to reconsider tooling rather than push through.
Can I do dual screening in Zotero?
Not blinded, and not with conflict resolution. Use Zotero to assemble and de-duplicate, then a dedicated screening platform.
References
- Duplicate detection — Zotero documentation
- Collections and tags — Zotero documentation
- Managing and counting duplicates for reviews — Zotero Forums
- Zotero and systematic reviews — Zotero Forums
