> ## Documentation Index > Fetch the complete documentation index at: https://studies-guides.jaspari.com/llms.txt > Use this file to discover all available pages before exploring further. # Roles & Permissions > Five organization roles control what a team member can do. Access scope can further narrow which studies and sites they see. Both combine with any collaboration tier your organization holds on a shared study. Every person on your team gets one of five roles. The role controls what they can do across your organization. ## The five roles Full access. The only role that can manage the team, billing, organization settings, and study ownership. Every organization must have exactly one Organization Admin. The Organization Admin may alter their [Visibility](/compliance/volunteer-data-visibility) set to anonymized or none, if needed. Runs studies and sites day to day. Can create and edit studies, launch/pause/end them, share a study with another organization, manage sites, and work volunteers. Cannot touch billing, organization settings, team management, or study ownership. Works the recruitment pipeline. Can update a volunteer's status, add notes and follow-ups, book and reschedule visits, reassign a volunteer to a different site, add a volunteer manually, and submit corrections to volunteer details for verification. Cannot change any study, site, billing, or organization setting. Sees everything, and additionally handles money: invoices, payment methods, wallet deposits, payments. Cannot change a volunteer's status, a study, a site, or organization settings. Billing admins should have their [Visibility](/compliance/volunteer-data-visibility) set to anonymized for auditing or none. Views everything within their scope. Writes nothing. A clinic with a front-desk coordinator, a study manager, and an office manager who handles invoices might set the coordinator up as a Team Member, the study manager as an Organization Manager, and the office manager as a Billing Admin. This keeps billing separate from day-to-day study work. ## Inviting a team member Go to **Settings → Team**. You must choose a role before the invite can be sent. The invite is valid for 7 days. If it isn't accepted in that window, it expires and can be re-sent. Once accepted, the person shows up in your team list with the role you assigned. You can change a person's role, or remove them from the team, at any time from the same page. ## Narrowing access with scope Independent of role, a team member's access can be set to **all** studies and sites, or **restricted** to a specific set. A restricted person sees the union of whatever individual studies and sites they've been granted, and nothing outside that, regardless of what their role would otherwise allow them to reach. Scope only narrows *what a person can see*. It works within a role's existing capabilities: a restricted Team Member still can't edit a study, for instance, even for a study they've been granted access to. An Organization Admin's role already implies full access, so this role stays unrestricted at all times. The other four roles can all be scoped. An Organization Admin may alter their own visibility of volunteers' data though. ## When your organization collaborates on someone else's study If another organization shares a study with you, your team members' access to that specific study is capped by two things at once: their own role at your organization, and the collaboration tier your organization was given on that study. Whichever is more restrictive wins. There are four collaboration tiers an organization can hold on a shared study: * **Owner**: the organization the study belongs to. * **Manager tier**: your Organization Admins and Managers can edit study setup and work volunteers. Your Team Members can still only work volunteers. * **Recruiter tier**: everyone at your organization, including your Organization Admin, is limited to handling volunteer statuses or adding to their pages (or viewing, depending on their own role). * **Viewer tier**: everyone at your organization can view the study, but nobody can make changes. If your organization is invited at Recruiter tier, your Organization Admin is limited to working volunteers on that study, the same as everyone else at your organization. The tier caps the whole organization, regardless of individual role. Your own sites, your own organization settings, and your own billing stay governed entirely by your team members' roles at your own organization. A collaboration tier on someone else's study has no bearing on any of it. See [Collaboration](/sharing/collaboration) for how sharing a study works, including ownership transfer and removing a collaborator. ## Volunteer data visibility Every team member gets a visibility level that controls which fields they see on volunteer records. This is separate from roles and access scope. Someone might be able to reach a volunteer's record but only see anonymized data, depending on their visibility setting. ### The three visibility levels **Full** shows everything: names, contact information, date of birth, notes, and local details. **Anonymized** hides direct identifiers. First names, last names, phone numbers, email addresses, and full dates of birth are not shown. Age still displays, calculated from the date of birth. Volunteers are identified by their public ID. Status notes and site-specific local details are also hidden. **None** blocks access to volunteer records entirely. The team member cannot see volunteer lists, detail pages, or visit records. ### Who controls visibility Organization Admins set the default visibility level when inviting a team member or editing their profile. Any team member can lower their own visibility at any time, but only an Organization Admin can raise it back up. An Organization Admin can raise their own visibility too, unless they've turned that ability off for themselves (see [Volunteer Data Visibility](/compliance/volunteer-data-visibility) for that option). When your organization collaborates on another organization's study, you can also set visibility on a per-study basis. This lets you give someone anonymized access by default but full access to one specific study, for example. Visibility mostly works independently of role. A Team Member with anonymized visibility still cannot edit a study setup, even if they're granted access to the study; their role prevents that rather than their visibility. The one exception is direct identifiers: at anonymized visibility, a person can't add or edit anything that requires entering an identifier (a status note, site-specific local details, a name/phone/email/date of birth, or adding a volunteer manually), even if their role would otherwise allow it (see [Volunteer Data Visibility](/compliance/volunteer-data-visibility) for the full list). Outside of that identifier-entry case, visibility only controls what data they see; it doesn't otherwise change what they can do based on their role. ## Related topics - [Volunteer Data Visibility](/compliance/volunteer-data-visibility.md) - [Inviting Team Members](/sharing/account-setup.md) - [Collaborate with Other Organizations on a Study](/sharing/collaboration.md) - [Payment Methods](/billing/payment-methods.md) - [Audit Log](/compliance/audit-log.md)