Campus users may be assigned varying levels of permissions and access level, depending on the institution's policies and needs. Site Administrators can manage many of these permissions and access levels using the Users tab, but some are managed by Campus Labs upon request. Most user access levels regarding projects/surveys in Baseline are dependent on your org chart, so make sure to work with your consultant to ensure this is up to date.

Important Terms to Know:

  • Institutional Level Access (Given to Site Administrators and controlled by Campus Labs) – Users with Institutional Level access have access to all departments and projects for their institution in Baseline. They are also able to see respondent identifiers in the exports of any project where identifiers were collected (unless explicitly hidden by Campus Labs or the creator of the project).
  • Department/Org Unit Level Access (Managed by Site Administrators) – Users with department/Org Unit level access can request projects within that department/org unit. They may also request and view projects for departments within that department (for example, a user with Department Level Access to Academic Affairs will be able to request projects for the Academic Affairs unit, as well as every unit within Academic Affairs).
  • Project Level Access (Managed by Site Administrators) – Users with Project level access are able to view specified projects as determined by their Site Administrator, which means they can send mass mailings and view results for the projects to which they have access.
    • Site Administrators can provide users from one department with project level access to a project in a different department, as well as block users from having access to particular projects within a department they user has access to. 
    • IMPORTANT: If Users with project level access do not have access to a department, they will unable to request projects for any departments. They will still be able to access the Community SiteRubrics, and the SRS.
  • System Roles (Managed by Site Administrators) - Additional permissions/responsibilities can be given to users by Site Administrators to help manage the Baseline Site and give access to some advanced features.
  • Custom Groups (Managed by Campus Labs upon request) – Custom groups are groups of users, separate from organization units that can be a combination of multiple departments or users from different departments.  Customized access rules must be assigned to custom groups, so that members of the group can view specified projects.
  • Hide Respondent Identity - Project Level (Managed per project by Site Admin and Project Creator) – By activating the Hide Identity feature in the Settings area of a project, the email addresses of respondents will not be included in the export.  The Hide Identity feature can be toggled for specific projects by Site Admin and the creator of the project.
  • Hide Respondent Identity - Department Level (Managed by Campus Labs upon request) –  The Hide Identity feature can be applied to entire departments/org units and to specified Baseline users.  Campus Labs can activate a Hide Identity override for users, so that they will always be able to see the identity of respondents for all projects where identity was collected (typically applied only to Site Administrators).

Your Org Chart and its Implications:

The org chart in Baseline plays a key role in user access levels. When a user is given Department/Org Unit level access to a department in the org chart, that user will also have access to any units within that unit. Much like the file folder system on your computer, when a user has access to one folder, they will have access to all of the folders within it. 

The graphic below demonstrates this concept of "inheritance." User A has Institutional Level access, so they are able to request and view projects throughout the entire org chart. User B has department/org unit level access to Academic Affairs, but since Academic Affairs has no child units, User B only has access to that one org unit. User C has department/org unit level access to Student Affairs, and as a result has also inherited access to the units within Student Affairs, and request and view projects in Residence Life and Orientation. Since Academic Affairs and Student Affairs are at the same "level" in the hierarchy as one another, User C cannot see or request projects in Academic Affairs, nor can User B see or request projects in Student Affairs.

Best Practices Regarding User Access:

  1. Consider adding a special org unit to your org chart to house "confidential" or "special" projects - To easily manage projects that need careful control over who has access to view respondent results, we recommend creating a designated org unit to house these projects in. In this suggested setup, Site Admin should never give Department/Org Unit Level Access to this unit; rather, they should only give project level access to users on a project-by-project basis and request that their Baseline Support Specialist move all designated projects to that org unit to ensure maximum confidentiality.
  2. Using a Validation Screen or a Mass Mailing to collect identifiers when administering a survey means that the survey will not be anonymous. Even if users choose to hide the respondent's identity, that setting can be toggled off upon request at any time. The respondent's identities are merely hidden from the user, not technically anonymous. If users choose to collect data using these administration methods, we recommend letting respondents know that their data is secure and confidential.

If you have additional questions you can contact our Support Team or call 716-270-0000 Monday through Friday 8:00am - 8:00pm EST.

Have more questions? Submit a request