# How to Manage Permissions in Collaborative Research Notes: A Guide The core difference between permission settings is who can change the record versus who can only look at it. A simple rule of thumb works for most labs and study teams: give edit access to the people producing the notes, comment or read access to people who need to stay informed, and admin access to as few people as possible, ideally one or two per project. This guide explains the main permissions for collaborative research notes, weighs the pros and cons of each option, and walks through concrete scenarios so you can decide what to set before the first shared note is written. ## Why permissions decide whether shared notes survive Collaborative research notes live or die on two things, trust in the record and willingness to contribute. Permissions control both. If everyone can edit everything, people hesitate to write candid observations because a careless edit can erase them. If almost nobody can edit, notes go stale and collaborators start emailing attachments instead, which fragments the record. The evidence from research collaboration studies points in a consistent direction. Teams that succeed at shared documentation tend to agree on working processes early and revisit them at regular intervals, rather than improvising norms as they go. The DAFNEplus program used a structured Collaborative Working Group process with monthly teleconferences and strategically timed face-to-face meetings to coordinate practitioners and researchers before a trial, and the authors noted that practical guidance for this kind of pre-trial collaboration had been lacking [1]. A permissions scheme is exactly the kind of working process that benefits from being agreed on in advance rather than negotiated during a crisis. A second reason permissions matter is that research notes are increasingly treated as analyzable data. Qualitative studies routinely draw on field notes and meeting notes as primary evidence. The FIRE implementation study analyzed notes from monthly internal-external facilitator teleconference meetings as part of its process evaluation [2]. The Liberia field survey study based its lessons-learned analysis on field notes produced by the research team [3]. Once your notes can become data, permission decisions acquire ethical weight, because access control is one of the mechanisms that protects the people described in those notes. ## Core concepts: roles, granularity, and scope Before comparing options, three terms need definitions because vendors use them loosely. A **role** is a named bundle of permissions, such as "viewer" or "editor," that you assign to a person or group. **Granularity** describes how finely you can control access, from a single on-off switch for a whole notebook down to per-page or per-section control for specific users. **Scope** is the level at which a permission applies, such as the whole workspace, one project, or one note. Research information management systems illustrate how far granularity can go. Djeen, a research information management system developed for collaborative projects in biology, stores heterogeneous data types while managing "advanced permissions" through roles, with permissions that are fine-grained for each project, user, and group [4]. The design goal was secure storage and annotation plus flexible data sharing across technologies, which is essentially the same problem a small lab faces with a shared notebook, scaled up. You do not need that level of engineering for most teams, but the underlying model is worth copying. Organize your notes into projects. Assign permissions at the project level by default. Grant per-note exceptions rarely, because every exception is something you must remember to revoke. ## The main permission options for collaborative research notes Most modern note platforms and electronic lab notebooks offer some combination of six options. Each is explained on its own terms with pros and cons. ### 1. View or read-only access A viewer can open and read notes but cannot change them. In research note taking, read-only is the correct setting for anyone who needs awareness without authorship, such as a principal investigator who wants to monitor progress, a collaborator at another institution who consults occasionally, or a new member learning the project history. **Pros:** The record is protected from accidental or unwanted edits, and readers can be granted access liberally because the risk is low. Read-only is also the natural setting for notes that have reached a milestone, such as a completed experiment series or a finalized protocol, since freezing a version of the record is standard good practice. **Cons:** Viewers who spot an error have to route the correction through someone with edit rights, which adds friction. If you set too much of the notebook to read-only out of caution, contributors stop treating it as a living document and keep parallel private notes. ### 2. Comment access A commenter can read notes and attach remarks, suggestions, or questions without altering the underlying text. This is the setting for reviewers, quality checks, and advisory input. **Pros:** Comments create an auditable trail of feedback that is separate from the record itself. In collaborative projects where practitioners and researchers exchange views, a comment layer lets both sides respond in place. Structured collaborative processes such as the Collaborative Working Group approach in the DAFNEplus study depend on regular, documented exchange between people with different roles, and a comment layer supports that exchange inside the notes rather than in scattered email [1]. **Cons:** Comment threads can balloon. Unresolved comments accumulate, and the distinction between the record and the commentary blurs if the team never resolves or archives threads. A useful norm is to require that a comment be marked resolved, or its substance merged into the note, before a meeting or milestone. ### 3. Edit access An editor can create and modify notes. This is the default for the people doing the work, and restricting it too tightly is the most common way teams kill a shared notebook. **Pros:** Real-time collaborative writing means the record reflects the current state of the work. For qualitative teams, this matters for rigor. Studies commonly use strategies such as investigator triangulation, peer debriefing, and field notes to establish trustworthiness, and shared editable notes make peer debriefing practical because a second team member can review and annotate what was observed [5]. **Cons:** Edit rights carry risk. Unintentional deletions, overwrites, and unattributed changes all become possible. Modern platforms mitigate this with version history, which preserves prior versions and shows who changed what, but version history only helps if the team knows it exists and uses it. Edit access should therefore be paired with a brief team norm, such as "use version history to recover anything" and "leave a comment when you restructure someone else's note." ### 4. Admin or manage access An administrator can change permissions themselves, add and remove members, delete content, and often export the whole workspace. Admin is a governance role, not a working role. **Pros:** Concentrating admin rights keeps the permission structure coherent. Someone has to own decisions such as who joins the project, what happens when someone leaves, and when a section is archived. Without a designated admin, those decisions default to whoever notices the problem first, which is not a governance system. **Cons:** Admin access is a single point of failure. If the sole administrator leaves the institution without transferring rights, the team can be locked out of its own record. Admins can also, deliberately or accidentally, alter the record in ways others cannot see. The practical mitigation is to name at least two admins per project and to log admin-level actions where the platform supports it. ### 5. Group and role-based permissions Instead of assigning permissions person by person, you assign them to groups such as "lab members," "collaborators," or "data managers," and each group carries a permission level. This is the model Djeen adopted, managing advanced permissions through roles with per-project, per-user, and per-group granularity [4]. **Pros:** Group-based permissions scale. When a new graduate student joins, you add them to the "lab members" group once and they inherit the right access everywhere, rather than being granted it notebook by notebook. It also makes audits easier, because reviewing group membership reviews access for everyone at once. **Cons:** Groups require maintenance. Stale groups are dangerous, because a person who left the project in March may still hold edit rights through a group nobody cleaned up. Groups also abstract away exceptions, so a reviewer who needs edit rights on one protocol may end up quietly added to the editor group project-wide. ### 6. External and link-based sharing Many platforms let you share a note or notebook with people outside your organization, either by inviting a named external user or by creating a link that anyone with the link can open, sometimes with an expiration date or password. **Pros:** External sharing is how cross-institution collaborations and advisory groups actually read your notes without being onboarded into your internal systems. For multi-site projects, where coordination happens across institutions, some form of external access is usually unavoidable. **Cons:** Link-based sharing is the least controllable option. Links get forwarded. A link that grants view access today may keep working after a collaborator's involvement ends. For research notes that contain identifiable information about participants, external link sharing is generally inappropriate, and named-user invitation with the narrowest permission level is the safer route. ## Side-by-side comparison The table below is the core of this guide. Use it to shortlist an option, then read the scenario section for your situation. | Option | What the person can do | Best suited for | Main risk | Reversibility | |--|--|--|--|--| | View (read-only) | Open and read notes | PIs monitoring progress, consultants, archived records | Corrections route through editors, adding friction | Very easy, widen anytime | | Comment | Read and attach feedback | Reviewers, advisory input, peer debriefing | Unresolved comment threads accumulate | Easy | | Edit | Create and modify notes | Active contributors doing the work | Overwrites and accidental deletions without version history discipline | Moderate, requires fixing changes | | Admin | Change permissions, add or remove members, delete content | One or two owners per project | Lockout if the sole admin leaves, invisible alterations | Hard, depends on the platform | | Group or role-based | Inherits a permission bundle per project | Teams with turnover, multi-project labs | Stale group members retain access | Moderate, requires group hygiene | | External or link sharing | Outside users open notes, sometimes via link | Cross-institution collaborators, advisory groups | Link forwarding, lingering access after a project ends | Variable, weak for links | ## How to manage permissions in collaborative research notes over time ![Flowchart from writing the scheme at project start through personnel changes and audits to freezing finished sections read-only.](/article-images/illustrations/permissions-for-collaborative-research-notes-permission-lifecycle.webp) Setting permissions once is easy. Keeping them correct is the actual skill. The experience of multi-site and multi-role research programs suggests a rhythm. **At project start, write the permission scheme down.** One short paragraph per project, naming the admins, the editor group, and who gets comment or view access. The act of writing it forces the team to make the decisions that would otherwise be made ad hoc. Structured collaborative processes work partly because they make roles and communication explicit rather than assumed [1]. **At every personnel change, act the same day.** When someone joins, add them to the correct group, not to individual notes. When someone leaves, remove them from groups first and check for per-note exceptions second. In multi-site facilitation work, difficulties arose in part from coordination failures across people and sites, and personnel transitions are the classic moment where access control quietly fails [2]. **At regular intervals, hold a permissions check.** Attach it to an existing meeting so it actually happens, for example the first team meeting of each semester or the monthly teleconference many collaborative programs already run. The check takes ten minutes, review the member list, the admin list, and any external shares. Field research teams juggling instruments, timestamps, and notes have documented how workflow and cognitive load strain documentation practices, and an unreviewed permission structure compounds exactly that load when something goes wrong [6]. **At milestones, freeze what is finished.** Switch completed sections to read-only or duplicate them into an archived project. This preserves the record that later analysis, writing, or audit will rely on, while leaving active sections editable. ## Permissions, data governance, and ethics Permission settings inside a note tool are one layer of access control, but they interact with formal governance obligations, and conflating the two is a genuine mistake. Formal data access in health research runs through explicit approval pathways. To access anonymized data from Ireland's Maternal and Newborn Clinical Management System for research, a researcher must submit a detailed protocol and data collection sheet for national-level approval, complete a Data Protection Impact Assessment, and obtain permission separately from each maternity unit's ethics committee before any data is extracted and transferred [7]. A workspace permission toggle does not substitute for any of that. If your collaborative notes contain participant data, the permission scheme inside the tool must be at least as restrictive as what your ethics approval allows, and ideally more so. Consent is a related but distinct layer. In the UNRAVEL research data platform for cardiomyopathies, eligible participants and their relatives are asked for permission to use their data and blood for biobanking before anything enters the research database [8]. Participants consent to researchers using data, not to an unrestricted internal audience reading them. When a participant's information appears in study notes, the set of people who can open those notes should be defensible in terms of the consent obtained. Ethical fieldwork raises the stakes further. The Liberian field survey study emphasized respectfully transparent interactions with respondents and communities, and drew its methodological lessons from analysis of the team's own field notes [3]. If field notes describing vulnerable participants sit in a shared workspace, granting broad edit or link access to convenience is a decision with consequences for real people, not just a workflow preference. ## Choosing the best permissions for collaborative research notes ![Decision path asking whether the person writes notes, only reviews them, or needs to manage access, ending in edit, comment or admin rights.](/article-images/illustrations/permissions-for-collaborative-research-notes-permission-triage.webp) Three criteria decide real choices more than any feature list does. **Sensitivity of content.** Notes containing identifiable participant information, unpublished results with commercial value, or data governed by an agreement demand the narrow settings, named-user access, view or comment for outsiders, admin held by the data owner. Generic brainstorming or meeting logistics can tolerate broad access. **Team size and turnover.** A two-person collaboration can use per-person permissions without cost. A lab with rotating undergraduates, visiting scholars, and external collaborators almost always benefits from group and role-based permissions, because manual per-person grants do not survive turnover. This is the setting where research information systems adopted role-based, fine-grained access in the first place [4]. **Stage of the work.** Early-stage exploratory notes benefit from broad edit access, because the value at that stage is rapid capture. Milestone-stage notes benefit from freezing. Projects in the analysis and writing phase benefit from a comment layer, since the work shifts from producing notes to reviewing them. A useful default for a mid-sized academic team is the 80/15/5 pattern. Roughly 80 percent of members sit in an editor group for their own projects, around 15 percent hold comment or view access across projects for awareness, and about 5 percent, one or two people, hold admin rights. Treat those as proportions to aim at, not rules, and adjust for your platform's options. ## Worked scenarios ### Scenario 1: A wet-lab team with rotating undergraduates A [molecular biology](/blog/careers/molecular-biology) lab runs three projects. Two graduate students lead them, four undergraduates rotate through, and the PI oversees everything. The best permissions for collaborative research notes here are group-based. Create a "Project A editors" group containing the lead graduate student and any undergraduates assigned to Project A, the same for Project B, and a "lab readers" group containing everyone including the PI. Admin rights go to the PI and the lab manager. When an undergraduate rotates off a project, removing them from that project's editor group takes one action. When a visitor arrives for a two-week stay, they join the readers group and receive editor rights on exactly one notebook if needed. This mirrors the role-and-group model that research information management systems use for exactly the reason of flexible, fine-grained project access [4]. ### Scenario 2: A multi-site qualitative study with sensitive field notes A three-site study collects interviews and field observations about patient experiences. Site coordinators write field notes, the analysis team codes them, and an advisory group oversees the work. Because the notes describe identifiable people, external link sharing is off the table. Site coordinators get edit rights in their own site's folder only, the analysis team gets edit rights in a separate analysis folder with read access to site folders, the advisory group gets comment access to a curated summary folder rather than the raw notes, and admin sits with the study coordinator and a backup. This structure aligns the tool's permissions with the governance logic that data access requests to clinical record systems follow, where separate approval is required at each contributing site [7]. It also supports the documented-exchange practices that structured collaborative working depends on, with the advisory group responding in place through comments rather than reshaping raw records [1]. ### Scenario 3: A solo researcher building a literature notes system A postdoc maintains a [literature notes system](/blog/research-skills/the-ultimate-guide-to-building-a-literature-notes-system-for-research) for a review, with one note per paper, linked by topic tags, plus synthesis notes. She invites her supervisor and one coauthor. The right setup is modest. Her literature notes remain private or view-only for the coauthor, the synthesis notes are shared with edit rights because the coauthor contributes arguments, and the supervisor gets view access across the system. Research note taking at this scale does not need groups or admin hierarchies, and over-structuring it costs more time than it saves. If a second coauthor joins months later, promote the system to two groups rather than stacking per-person grants. ## Common mix-ups - **Confusing comment rights with edit rights.** A commenter can shape perception of a note through remarks but cannot fix an error in it. Teams that intend "people can correct mistakes" and set comment-only get frustrated within weeks. - **Granting admin to be polite.** Admin rights are a governance duty, not a courtesy or a reward for seniority alone. If a senior collaborator does not actually manage access, view or comment access serves the relationship better. - **Sharing links instead of people.** A forwarded link defeats the entire permission model. For anything with participants in it, invite named users. - **Building exceptions instead of changing the structure.** If you find yourself granting five per-note exceptions, the underlying project structure needs adjusting, not more overrides. - **Treating tool permissions as ethics compliance.** Ethical approval, data sharing agreements, and participant consent govern what may be shared at all. Workspace permissions control who can reach what already exists inside the tool. Both layers are needed, as the approval pathways for clinical record access make clear [7]. - **Freezing everything out of caution.** Read-heavy permission schemes push contributors back to private notes and email, which is the fragmentation the shared notebook was meant to prevent. - **Forgetting version history.** Edit access plus version history is a safe combination. Edit access without the team knowing version history exists is not, because nobody recovers overwrites and everybody blames the platform. ## Common Mistakes and Limitations The mistakes above are operational. This section covers the ones that surface later, when they cost more. **Orphaned admin access.** When a sole administrator leaves the institution, the team can lose the ability to manage its own record, and recovery depends entirely on institutional IT support. Name a second admin the day you name the first. **Permission drift.** Access granted for a deadline, a collaboration, or a review often outlives its purpose. Without periodic checks, the member list grows to include people with no current role, which both increases risk and makes the notebook feel less safe for candid notes. Multi-site programs that ran long-term coordination found that unmanaged coordination burdens undermined otherwise sound plans, and permission drift is a coordination burden of exactly that kind. **Assuming notes are not data.** Teams are often surprised that their notes are later requested for analysis, audit, or publication. Qualitative studies treat field notes and meeting notes as analyzable evidence [5][3]. Write your notes accordingly, and set permissions for the record you might have someday, not just the one you have today. **Inconsistent time-stamping and synchronization in field settings.** Field research combining instruments and ethnographic notes has documented real difficulty synchronizing instrument outputs with notes and managing cognitive load during observation [6]. If your permissions depend on notes being filed promptly into the right shared folder, an unreliable filing workflow undermines them. Assign explicit ownership for filing when notes are captured under demanding conditions. **The limitation of any scheme.** Permission structures manage access, not behavior. A teammate with legitimate access can still misattribute an idea, alter a record ambiguously, or share a screenshot. Team norms, authorship agreements, and version history address those risks, and no permission menu replaces them. Every research team should also verify what its specific platform can and cannot do, because capability names and limits differ between products and change over time. ## Frequently Asked Questions ### What permissions should I give a new student joining a lab? Start with view or comment access to the whole project and edit access only to the section they will actually write in. Move them into the project's editor group once they have demonstrated they understand the note-taking conventions, which usually takes a few weeks. ### Can I just give everyone edit access and sort out problems later? You can for a small team working on low-sensitivity content, and many two or three person collaborations do exactly that. The approach fails as team size and content sensitivity grow, because you lose the ability to distinguish who contributed what and who should reach participant-related material. ### Do workspace permissions replace ethics approval and data agreements? No. Ethics approval, data protection assessments, and sharing agreements determine whether information may be shared and with whom in a legal sense, while workspace permissions are a technical layer that must be set to match or be stricter than those obligations. ### Should my literature notes system use the same permissions as my lab notes? Usually no. Literature notes summarize published work and carry little sensitivity, so broad edit access among coauthors is fine, whereas lab notes describing unpublished results or participants warrant narrower, role-based control. ### How often should a team audit its permissions? Once per term or quarter is sufficient for most academic teams, attached to an existing meeting so it happens. Audit immediately and additionally whenever someone joins, leaves, or changes role, since personnel transitions are when access errors occur. ### What is the difference between role-based and per-person permissions? Per-person permissions assign a level to each individual, which is precise but does not scale, while role-based permissions assign levels to groups that individuals join or leave, which scales cleanly but requires the groups themselves to be kept current. ## Sources 1. [Mobilising knowledge between practitioners and researchers to iteratively refine a complex intervention (DAFNEplus) pre-trial: protocol for a structured, collaborative working group process.](https://pubmed.ncbi.nlm.nih.gov/29988686/) 2. [Designing and implementing two facilitation interventions within the 'Facilitating Implementation of Research Evidence (FIRE)' study: a qualitative analysis from an external facilitators' perspective.](https://pubmed.ncbi.nlm.nih.gov/30442157/) 3. [Conducting Ethical Field Research on Rape in West African Settings: Case Study of 2018 Liberian Field Survey.](https://pubmed.ncbi.nlm.nih.gov/38063621/) 4. [Djeen (Database for Joomla!'s Extensible Engine): a research information management system for flexible multi-technology project administration.](https://pubmed.ncbi.nlm.nih.gov/23742665/) 5. [Evaluation of patient involvement in patient safety in cardiovascular surgery intensive care units: a qualitative study.](https://pubmed.ncbi.nlm.nih.gov/41559575/) 6. [Integrating portable X-Ray fluorescence and personal air sampling into ethnographic field research during agrichemical fumigation in an avocado orchard: field challenges encountered and lessons learned.](https://pubmed.ncbi.nlm.nih.gov/42231397/) 7. [Accessing Anonymised Data from Ireland's Maternal and Newborn Clinical Management System for Research Purposes.](https://pubmed.ncbi.nlm.nih.gov/40051763/) 8. [UNRAVEL: big data analytics research data platform to improve care of patients with cardiomyopathies using routine electronic health records and standardised biobanking.](https://pubmed.ncbi.nlm.nih.gov/31134468/)