Citation Management Software for Research Groups

Almost every guide to citation management software answers a personal question: which reference manager should I install. That question is already settled territory — if you are still choosing a tool, start with the five-way comparison of Zotero, EndNote, Mendeley, RefWorks and Paperpile, or the narrower head-to-heads on Zotero vs. EndNote and Zotero vs. Mendeley.

This page answers the question that follows and is almost never written down: how do you run one shared library for a group of people who join and leave? A research group is not a user. It is a rotating population of PIs, postdocs, PhD students, research assistants and visiting collaborators, attached to an institution that licenses some tools and not others. The failure modes are completely different from personal use, and the worst of them — a shared library that becomes unreachable because the person who owned it left — is an account-configuration decision made on day one, not a software feature you can compare on a table.

The three decisions that differ from personal use

When a single researcher picks a reference manager, the decision variables are citation styles, PDF handling and word-processor integration. When a group deploys one, three different variables dominate, and none of them appear on a standard feature comparison:

Who owns the shared library — which single account holds it, and what happens to it when that account’s human leaves.
Who pays for file storage — group file storage is not always billed the way you would expect, and in at least one major tool it is charged entirely to one person.
Who can edit and delete — the default in most shared libraries is that every member can remove anything, and deletion propagates.

Everything below is organised around those three, plus the licensing models that determine whether a departing member keeps access at all.

Who owns the library when a postdoc leaves

This is the single most consequential setting in a group deployment, and it is the one most groups discover only when it is too late.

In Zotero, a group library belongs to a group owner — one account. Zotero’s role model has three levels: regular member, administrator, and owner. Administrators can change the group’s public/private status, change other members’ roles, and change library settings. The owner has all administrator privileges and, additionally, is the only role that can delete the group or transfer ownership to another member. Ownership transfer is initiated from the group’s profile settings using the Transfer Ownership option; only the current owner can initiate it, and the person offered ownership must accept before it takes effect. Once it does, group file storage begins counting against the new owner’s quota rather than the old one’s. (Source: zotero.org/support/groups, retrieved 2026-08-26.)

Read that constraint carefully, because it defines the risk: if the owner is a postdoc on a three-year contract, and that postdoc leaves without initiating a transfer, no administrator can take ownership on their behalf. The lab is left with a library it can still read and edit but cannot restructure, transfer or delete — and whose file storage is attached to a departed person’s subscription.

Zotero’s own recommendation, which is the actual answer

Zotero’s documentation states the mitigation explicitly. For a group belonging to a team, lab or organisation, it recommends setting up a separate account to function as the owner of the group, with at least two people knowing the login credentials, so that the group is not locked out if the owner leaves the team or organisation (same source, retrieved 2026-08-26).

In practice this means creating a role account rather than using a person’s account — a lab or project identity tied to a shared institutional mailbox that survives staff turnover, with the credentials held by the PI plus one other continuing member (a lab manager, departmental administrator, or the PI’s deputy). It is a five-minute decision at setup and an unrecoverable one afterwards. It is the same reasoning that applies to any research asset with a custodian, and it belongs in the same part of your group’s process as project offboarding.

The other tools resolve ownership differently

Zotero’s model is ownership by account. The commercial tools mostly use ownership by entitlement, which relocates the risk rather than removing it:

RefWorks is distributed almost entirely through institutional and library subscriptions rather than sold to individuals. The practical consequence is that a researcher’s access is a function of their institutional affiliation: it ends when they leave, and it ends for everyone if the institution drops the subscription. Export before departure is the only continuity plan — see RefWorks: what it is, institutional licensing, and how to migrate your library.
EndNote under a campus site licence behaves similarly at the licence layer, but its shared library is owned by the account that created it, and access for collaborators depends on their own EndNote accounts remaining valid.
Paperpile is per-seat, so a departing member’s seat is reassigned by the subscription administrator; the shared library persists with the subscription rather than with the individual.

The general rule: if the library lives inside a personal account, plan for succession; if it lives inside an institutional entitlement, plan for export. Both are plans. Neither is the default.

Who pays for shared file storage

Group storage economics are genuinely counter-intuitive, and this is where a lab’s costs concentrate.

Zotero syncs library metadata (the reference records themselves) without charge; only attached files — PDFs, snapshots, images — draw against a storage subscription. The individual tiers, verified directly against zotero.org/storage on 2026-08-26, are:

Storage limit	Cost (USD)
300 MB	Free
2 GB	$20/year
6 GB	$60/year
Unlimited	$120/year

The group-relevant clause is the one people miss: group file storage always draws from the storage account of the group owner, and other members’ quotas are not affected by group files at all. Zotero charges nothing extra for a group to use storage, and places no limit on how many members may join a group.

That combination produces a specific, predictable outcome. A twelve-person lab sharing annotated PDFs will exhaust a 300 MB free allowance almost immediately, and the entire overage lands on one person’s subscription. The correct configuration is that the role account which owns the group also holds the unlimited $120/year subscription, paid from a grant or departmental budget rather than from an individual’s pocket — which is a second, independent reason to use a role account rather than a person’s account as owner. Zotero also offers storage plans for labs and institutions beyond the individual tiers; those are quoted rather than list-priced, so confirm current terms with Zotero directly.

Paperpile takes the opposite approach — unlimited PDF storage is included on its subscription tiers — but gates the sharing features themselves behind the higher tier (see below). Mendeley’s storage allowances and EndNote’s are tied to their own account models. Where a specific current figure is not stated on this page, it is because it could not be confirmed against the vendor’s own documentation on the date given; do not carry a quota number over from a third-party comparison table, because these change without notice.

Seats and licensing: four models, four different group problems

Reference managers are not licensed the same way, and the licensing model — not the feature set — determines what happens as your group grows, shrinks and turns over.

Model	Example	What it means for a group	Failure mode
Free and open source	Zotero	No seats to buy or track; unlimited group members. Cost is storage only, billed to the owner.	Ownership succession; storage concentrated on one account.
Free proprietary	Mendeley (Elsevier)	No purchase, but terms, limits and roadmap are set unilaterally by the vendor.	Feature and limit changes you do not control.
Institutional site licence	EndNote (Clarivate)	Free at point of use for affiliated staff and students; the institution carries the cost.	Access is affiliation-bound; leavers and external collaborators fall outside it.
Library subscription only	RefWorks (Clarivate/ProQuest)	No individual purchase path; the library is the customer.	Total loss of access if the subscription lapses or affiliation ends.
Per-seat SaaS	Paperpile	Predictable per-person cost; seats reassignable by an administrator.	Cost scales linearly with group size; sharing may be a paid-tier feature.

Where collaboration is a paid feature, not a base feature

Paperpile is the clearest example of a trap that per-seat pricing creates. Verified against paperpile.com/pricing on 2026-08-26: the entry-level Regular plan is listed at $4.15/month with the 50% academic discount ($8.30 without), and the Expert plan at $5.75/month academic ($11.50 without), both billed annually. But shared folders, shared libraries, access permissions and collaborative PDF annotations are all Expert-tier features — they are not included in Regular. A group that budgets at the entry price and then discovers it cannot share a library has budgeted for the wrong plan. Paperpile also offers an Enterprise/Institutions tier, quoted rather than list-priced, which adds SAML single sign-on, custom MSA and SLA terms, and HIPAA provisions — relevant if your references sit alongside regulated data.

EndNote’s shared-library capability is reported to support sharing an entire library — references, PDFs and PDF annotations — with up to 1,000 collaborators, with per-collaborator read-and-write or read-only permission, and to require every collaborator to hold an EndNote Sync/online account in addition to the desktop application. That figure is reported-tier: it was confirmed on 2026-07-29 from multiple consistent university library guides rather than from a Clarivate primary specification, so verify it against Clarivate’s current documentation before relying on it for a procurement decision.

Not confirmed: current member and group-count limits for Mendeley private groups could not be verified against Elsevier’s own documentation on 2026-08-26 — the relevant Mendeley guide page renders its content client-side and returned no substantive text, and the support-hub article did not resolve. Older third-party figures circulate widely; they are not cited here because they cannot be dated to a current primary source. Check Elsevier’s Mendeley support centre directly.

Permissions: the setting that decides whether the library survives contact with the group

Shared libraries fail quietly, through permissions left at their defaults. Zotero exposes three independent library settings, and it is worth setting each deliberately rather than accepting whatever the group was created with (source: zotero.org/support/groups, retrieved 2026-08-26):

Library Reading — anyone on the internet, or any group member.
Library Editing — any group member, or only group admins.
File Editing — any group member, only group admins, or no group file storage at all.

The decision rule that works for most research groups: Library Editing set to any group member, File Editing set to any group member, Library Reading restricted to members — because the entire point of a shared bibliography is that co-investigators add to it without asking permission. Accept the trade-off consciously, though: it also means one member’s mis-tagged, duplicated or deleted entry is visible to everyone until someone cleans it up. Groups that hold a canonical, citation-ready library for a submitted manuscript or a systematic review protocol should restrict editing to admins and let members propose additions instead.

Two structural constraints are worth knowing before you pick a group type. A public, open-membership group cannot have file storage at all — anyone may join instantly, and shared PDFs are not available. Private groups are completely hidden from group searches, do not appear on members’ public profiles, and do not surface in search engine results, which is the appropriate setting for an unpublished manuscript’s working bibliography.

What actually breaks across a team

Three behaviours account for most of the confusion a shared library generates. None of them is a bug, and all of them surprise people arriving from single-user habits.

1. A group library is not a synced copy of your own

Group libraries are wholly separate from your personal library. When you drag an item from My Library into a group, you create a separate copy — subsequent edits to the group’s copy are not reflected in your own until you drag it back. Teams that assume a single item exists in two places, kept in step, will find their personal and shared metadata silently diverging. The workable pattern is to treat the group library as the single authoritative pool for that project and capture new references directly into it, rather than maintaining a personal library and periodically syncing.

2. Deletion is a group action

Where every member can edit, every member can remove. There is no per-member undo across a shared library, so an accidental bulk delete is a group-wide event. This is the strongest practical argument for taking a periodic export of the shared library — a full RIS or BibTeX dump stored with the project’s other materials — regardless of which tool you use. It also happens to be your migration path if you ever change tools, and your continuity plan if an institutional subscription lapses.

3. Duplicates accumulate faster than in a personal library

With several people capturing from several databases, the same reference arrives repeatedly with different metadata quality. Assign duplicate cleanup to a named person on a schedule — the same way a lab assigns responsibility for a shared freezer inventory — rather than assuming it is nobody’s job. Groups doing structured evidence work should handle deduplication in a purpose-built workflow instead; see the guidance on tools for systematic literature review.

The institutional support burden

If you are the person who will be asked to support this — a subject librarian, a research computing team, a departmental administrator — the questions that arrive are consistent, and are mostly not about the software:

“I left and lost my library.” An affiliation-bound licence question, not a technical one. The answer is an export procedure communicated before departure.
“Our group library is stuck.” Almost always an ownership problem — the owner has left. Prevented only at setup.
“Sync stopped working.” Usually the owner’s storage quota, or a client/plugin issue. For Zotero specifically, the diagnostic path is documented in Zotero setup and troubleshooting.
“Can our external collaborator have access?” Trivial in Zotero, which places no limit on member numbers and requires no licence. Frequently impossible under a site licence or library subscription, which is a genuine argument for Zotero as the inter-institutional collaboration layer even where EndNote is the local standard.

That last point deserves emphasis, because it is a decision most groups never consciously make: the tool your institution licenses and the tool your collaboration runs on do not have to be the same tool. Multi-institution consortia routinely keep the shared working bibliography in a free, licence-independent tool precisely so that access does not depend on any one partner’s procurement.

Group deployment checklist

Before the first reference goes in:

Create a role account to own the group, tied to a durable institutional mailbox, with credentials held by at least two continuing members. Do not use a fixed-term researcher’s personal account.
Attach the storage subscription to that owner account and fund it from a project or departmental budget, not an individual’s card.
Set the group type deliberately — private for unpublished work; remember that public open-membership groups cannot hold files.
Set reading, library-editing and file-editing permissions explicitly rather than accepting defaults, and record the choice.
Name a librarian-of-record responsible for duplicate cleanup and metadata hygiene, and put it in the group’s onboarding notes.
Schedule a recurring export (RIS or BibTeX plus attachments) stored with the project’s other research materials.
Add “export your references and confirm ownership transfer” to the group’s offboarding checklist, and check it whenever anyone leaves — especially the owner.
Verify current vendor limits at procurement time. Storage quotas, seat prices and collaborator caps change; the figures on this page are dated for exactly that reason.

Frequently asked questions

What is the best citation management software for a research group?

For a group specifically — as opposed to an individual — Zotero’s model has the fewest structural obstacles: no limit on member numbers, no per-seat licence to buy or track, no affiliation requirement that excludes external collaborators, and free metadata sync. Its cost concentrates in file storage, billed to the group owner. Where an institution already holds an EndNote or RefWorks licence, that tool may be the better default for internal work while a licence-independent tool carries cross-institutional collaboration. On tool features rather than deployment, see the full comparison.

Who owns a shared reference library?

In Zotero, one account: the group owner, who alone can transfer ownership or delete the group, and whose storage quota carries the group’s files. In subscription-based tools, the institution or the subscription administrator effectively owns continuity of access. In neither case does ownership default to “the lab” — you have to configure that.

How many people can share one library?

Zotero places no limit on how many members may join a group (zotero.org/support/groups, retrieved 2026-08-26). EndNote’s shared-library collaborator cap is reported at 1,000 with per-collaborator read/write or read-only permissions, from consistent university library documentation rather than a Clarivate primary source. Current Mendeley private-group limits could not be confirmed against Elsevier’s own documentation on 2026-08-26.

What happens to a group library when the person who created it leaves?

Nothing automatic. The group persists and members retain their existing permissions, but ownership does not transfer on its own and no administrator can seize it — only the departing owner can initiate a transfer, and only while their account is still active. If they leave without doing so, the group cannot be transferred or deleted and its file storage remains attached to their subscription. This is why Zotero itself recommends a shared team account as owner.

Does group storage count against every member’s quota?

In Zotero, no — group file storage draws entirely from the group owner’s storage account, and other members’ quotas are unaffected (zotero.org/storage, retrieved 2026-08-26). This is the reverse of what most people assume, and it is why the owner account needs the subscription.

Can we use a different tool from the one our university licenses?

Usually yes, and for multi-institution work there is a real argument for it. A licence-bound tool cannot easily include collaborators outside the licensing institution; a free tool can. Nothing prevents a researcher from maintaining an institutionally-licensed personal library and participating in a group library hosted elsewhere, provided you plan the export path in both directions.

Citation Management Software for a Research Group: Shared Libraries, Licensing, and Ownership

Ask about Citation Management Software for a Research Group: Shared Libraries, Licensing, and Ownership