Table of Contents
Overview
Best Practices
Recommended Permission Settings
Related Articles
Overview
PATH: Academic Scheduling > Settings > Roles
Role permissions dictate what users are able to see and do throughout our platform.
This particular article lists role configuration best practices.
For a more detailed look at setting up roles, see “Related Articles” below.
Best Practices
Disable Areas Not in Use | Instructor Dashboard | Consider your Coursedog Product Suite
Consider the Integration Scope | Consider Whether or Not the Permission is Relevant to the Role
Consider SIS-Specific Permissions | Consider SIS Restrictions
Disable Areas Not in Useins
You should "disable" any functional areas your institution doesn’t use.
For example, most institutions do not utilize the Section or Exam Optimizers for their first term. As such, you should make sure that every single role has their Optimizer permissions set to “Deny”.
Similarly, Preference Forms are also oftentimes not utilized by institutions when first implementing Coursedog.
Instructor Dashboard
The “Show Dashboard” permission under “Instructor Dashboard” should only be set to “Allow” for instructors (i.e. Users not involved in section data manipulation / scheduling).
When “Instructor Dashboard > Show Dashboard” is set to “Allow”, the Academic Scheduling homepage will not display the list of Departments / Section Dashboard. Hence, you don’t want this set to “Allow” for anyone other than instructors.
A sample view of the Instructor Dashboard is shown below.
Consider Your Coursedog Product Suite
Some permissions shown in Academic Scheduling > Settings > Roles are only relevant if you are utilizing other Coursedog products. If you are not utilizing these products (yet!), you should set these permissions to “Deny”.
The following permission is only relevant to institutions utilizing Coursedog Events: Institution Settings > Edit Term Date Exceptions.
The following permissions are particularly relevant to institutions utilizing Coursedog Curriculum. However, depending on your SIS they may be enabled for non-Curriculum institutions as well. You should confirm with your Coursedog representative whether these should be enabled for your institution.
Course Editor > Add Courses From Curriculum
Requests > Add Sections From Course Inventory
Consider the Integration Scope
Overview | Bi-Directional | Uni-Directional | Un-Integrated | Role Permissions Impacted by Integration Scope
Overview
Keep in mind that the scope of your integration will determine whether some permissions should be enabled or not. There are three main categories of integration scopes: bi-directional, uni-directional, and un-integrated.
Bi-Directional
We GET data from the SIS and bring it into Coursedog.
We are additionally able to POST data from Coursedog back to the SIS.
Example entity: Sections (we GET section data from the SIS, users manipulate it in Coursedog, and we then POST those updates to the SIS)
Uni-Directional
We GET data from the SIS and bring it into Coursedog. However, we are NOT able to POST data from Coursedog back to the SIS.
Example entity: Rooms, Instructors (while we GET this data to facilitate assigning these objects to sections, we do not POST instructors nor rooms themselves back to the SIS. We do, however, POST section data which may include a specific instructor/room assignments).
It is particularly important to be mindful of any uni-directional integration. Broadly speaking, if we GET data for a particular entity (or field) but cannot POST it back to the SIS, then that entity (or field) should be uneditable in Coursedog in order to avoid the integration overwriting data set in Coursedog.
The Academic Scheduling entities with which we typically have a uni-directional integration are: Rooms, Buildings, Instructors, Departments, Terms, Courses, and (sometimes) Relationships. Keep in mind, however, that this varies by SIS. Check with your Coursedog representative if you are unclear on your particular integration scope.
Un-Integrated
While rare, some institutions opt for a fully un-integrated approach, where we load data via CSV into Coursedog and then allow users to manipulate it. The institution is responsible for uploading or manually inputting this data back into their SIS. Data is in no way connected to the SIS.
Role Permissions Impacted by Integration Scope
Specific role permissions to keep in mind given the above are:
Course Editor > Add Courses
Course Editor > Edit Courses – If there is Coursedog-owned data you are utilizing, you may leave this set to “Allow”. However, ensure your Course Template has any SIS-owned field marked as uneditable to avoid the integration overwriting data.
Course Editor > Add Instructors
Course Editor > Edit Instructors – If there is Coursedog-owned data you are utilizing, like Instructor Bio, you may leave this set to “Allow”. However, ensure your Instructor Template has any SIS-owned field marked as uneditable to avoid the integration overwriting data.
Rooms > Add Rooms
Rooms > Edit Rooms – If there is Coursedog-owned data you are utilizing, like Room Allowed Sections or Blocked Out Times, you may leave this set to “Allow”. However, ensure your Room Template has any SIS-owned field marked as uneditable to avoid the integration overwriting data.
Buildings > Edit Buildings
Relationships > Edit Relationships – If we have a bi-directional integration integration with your SIS, you may leave this set to “Allow”.
Relationships > Add Relationships – If we have a bi-directional integration with your SIS, you may leave this set to “Allow”.
Consider Whether or Not the Permission is Relevant to the Role
Some permissions will only apply to certain roles.
Whether or not you set Course Editor > View Section Integration Status to “Allow”, for example, is at the discretion of the institution and the implementation team.
If set to Allow, this permission allows a user with this Role to view the section's integration status upon opening it in the Section Dashboard.
The best practice recommendation is that, if a user is familiar with merge errors and would be able to fix most of the errors they would see listed, then their Role should be able to see Integration Status.
However, if a given Role is unfamiliar with or unable to resolve merge errors, then the permission should be set to DENY for that Role. This permission is typically limited to Admins.
Consider SIS-Specific Permissions
Some role permissions may not be applicable to your SIS. If this is the case, you should set them to DENY.
SIS-specific permissions include:
Course Editor > Select Section Type For New Sections – This is specific to PeopleSoft, where some Section Types have different default values such that the user must select the Section Type before a Section gets created.
Course Editor > Allow Duplicate Instructors in Section – This is specific to PeopleSoft, which allows the assignment of the same instructor multiple times to the section, whereas most other SIS do not.
Consider SIS Restrictions
If your SIS does not allow you to perform a certain action, you should set up rules and role permissions in Coursedog to match those restrictions in order to avoid users committing violations that may lead to integration errors.
Some specific Role permissions worth noting are outlined below.
Course Editor > Delete Sections – One common example involving role permissions is the Course Editor > Delete Sections permissions. The vast majority of SIS have stringent rules around deleting (NOT inactivating) sections. As such, most institutions set this permission to DENY.
Requests > Delete Section – See rationale above.
To learn more about best practices for your given SIS, refer to these resources.
Related Articles