SSC Campus (Configuration) Decision-Making Guide I

This section details the questions that need to be answered to generate the configurations required for Go-Live. These must be answered and input to the platform with sufficient time prior to training to audit, test, and revise them.

User Roles

A role is how SSC Campus determines what type of user is logged into the system and the corresponding actions that user is able to perform. The role also affects how a user is tied to certain data points in the system.  For example, if a user is marked with the Professor role, they will have a Professor home page, and the courses they teach and students in their courses will be associated with them in the database for searches and reports.

Role Management

Create a strategy for assigning and removing user roles.

Roles that are pulled directly from or derived from the student information system (SIS) will be allocated to users and removed as these roles change in the SIS through nightly data feeds. Create a Strategy for Assigning and Removing User Roles.

For roles that cannot be tracked through the SIS, a manual update strategy is needed to manage granting and removing these roles to the appropriate staff or students over time.

Example Process to Grant a Manually Managed Role

  1. Application administrator receives request for access through SSC Campus help inbox.
  2. Application administrator determines appropriate role for user/ if access is needed and appropriate.
  3. Application administrator grants individual user appropriate role through SSC Campus directly.
  4. Application administrator responds to requester with either access or reason why access was not granted.

Example Process to Remove a Manually Managed Role:

  1. HR or other relevant department notified application administrator of transition in role or faculty/staff/student leaving the institution.
  2. Application administrator removes the user's roles through SSC Campus directly.

Best Practice: Conduct Role Audits at End of Term
Manually added roles not be removed from an individual until an application administrator manually removes access from an individual user or group of users. The application administrator(s) should run and review lists of staff and faculty who have access to the system at the end of every term to ensure that those have left the institution or moved to different roles do not maintain access to student data that is not appropriate.

How To: Lists of which users are currently assigned to each role can easily be run by an application administrator in the advanced search by selecting All Users as under Type, and then specifying the desired role.

Configuration Decision:

  • Who will manage user access at your institution?
  • What will your manual processes to add/remove access look like?
  • How will you respond to access requests?

Detailed Permissions

In addition to permissions restricting access to student profiles, there are over 150 specific user permissions and features that can be enabled or disabled for each user role. Setting these permissions will include the answer to questions such as:

  • Who should be able to create/edit appointments?
  • Who should be able to record notes?
  • who should be able to access the student profile?
  • Who should be able to create advising/ progress report campaigns?
  • Who should be able to run filtered lists?
  • Who should be able to issue alerts?
  • Who should be able to start center/kiosk mode?
  • Who should be able to access reports?

Configuration Decision: Please review the detailed permissions document, including the provided recommendations for the Advisor role. Make any needed changes for your institutions preferences, and use this configuration to inform your decisions on the permissions that should be allocated to each other role chosen above. Please contact your dedicated consultant with questions about specific permissions.

Services

Students and advisors schedule appointments for reasons, or services specified through the platform. A user must also specify the location where this service will be provided. This is not the place for users to specify their specific physical location (i.e., 405 Murphy Hall) but rather the administrative unit (i.e., Career Center, Center for Student Success).


Configuration Decisions:

  • What service categories should be available for students when scheduling? (i.e. Advising)
  • What individual services are offered at each location? (i.e. Changes to schedule) What types are they? (i.e. Advising, Tutoring, Other)
  • What locations offer these services? (i.e. COE Student Success Center)

Reasons

When users create a note for a student, they will have the option to select a specific reason to attach to it. These can outline common reasons for notes to reference in reporting or just for reference for an individual advisor or faculty member. Similarly, when an advisor or other user cancels an appointment, they will be prompted for a reason. Common selections include options such as cancelled--student request or cancelled--advisor request, but others may be appropriate for your institution.

Configuration Decisions:

  • What reasons should be available when adding a note to a student's profile?
  • Which reasons should be available when cancelling an appointment?

Depending on the selected permissions, users may have the ability to issue alerts for students. Alerts can be issues for customized reasons, and have specific workflows attached to each of them. For example, some alerts can be issues for informational purposed (i.e., attendance issues) where as others may create cases that can be assigned to a particular individual who is responsible for follow-up (i.e., behavioral issues in class).

Configuration Decisions:

  • Do you want to use the early alert feature?
    • What reasons should be available when submitting an alert? (i.e., Family Emergency, Needs Tutoring, etc.)
    • Which reasons should be available to faculty when responding to a progress report campaign?
  • Do you want to use the cases feature?
    • If so, which of these alert reasons should open a case?
    • If so, who should be assigned to the cases generated for each alert reason, if anyone?
  • If so, which alerts should trigger an email to the student?  What should the text of that email be?
  • Do you want a user to receive an email when they are assigned to a case?
  • Do you want a user to receive an email with case details when they are marked as the owner of a case?
  • What outcomes should be available for staff when closing cases?