Skip to main content
Separate from what a person can access (their role, and their organization’s standing on a shared study), volunteer data visibility controls how much of a volunteer’s record they can actually see once they reach it.

​
The three levels

  • Full: all study-relevant volunteer data is visible.
  • Anonymized: all study-relevant volunteer data is visible except direct identifiers: first name, last name, phone, email, and full date of birth, plus status notes and site-specific local details. The volunteer is identified by their public ID instead of their name.
  • None: no volunteer data is visible. Lists appear empty and the volunteer detail page is unavailable.
Visibility settings apply everywhere volunteer data appears: pipeline views, the volunteer list, the screening queue, scheduled visits, appointments and calendars, volunteer detail pages, status history, and audit log entries about a volunteer. At Anonymized, viewing is unaffected for everything else, but adding or editing a status note, editing site-specific local details, changing a name/phone/email/date of birth, and adding a volunteer manually are all blocked, since those all involve entering or editing a direct identifier.

​
Who sets it

Each person has a default visibility level tied to their role, set automatically when they join and adjustable by an Organization Admin from Team settings. An Organization Admin can also raise or lower a specific teammate’s visibility for an individual study. Anyone, including an Organization Admin, can lower their own visibility at any time. For everyone else, raising visibility back up always requires an Organization Admin to do it on that person’s behalf. An Organization Admin can also raise their own visibility, unless they’ve turned that ability off for themselves.
Because Organization Admins control visibility, they can optionally turn off their own ability to raise their own visibility, so that only a Platform Representative can do it for them. This prevents any future changes to their own visibility without involving Jaspari, and may be necessary to comply with your organization’s rules.
For the full permissions model this sits alongside, see Roles & Permissions.