Roles & Permissions

Every person on your team gets one of five roles. The role controls what they can do across your organization.

​

The five roles

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

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.

​

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.

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.

​

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 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 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.