Coursedog allows institutions to set a variety of permissions by assigning roles to their users, differentiating between a faculty member that makes a curriculum request and an admin that manages forms and workflows.
Available Roles
PATH: Curriculum Management > Settings > Roles
There are several delivered user roles in Curriculum Management to select from, or you may choose to design and add a new role if one is needed.
Preloaded roles include Super Admin, Curriculum Admin, Curriculum Requester, Curriculum Approver, Curriculum Department Admin, and Instructor.
Adding a Role
Overview
If you determine you need roles beyond what is preloaded, follow the below instructions to add a custom role.
How to Do It
Step 1:Navigate to Curriculum Management > Settings > Roles
Step 2: Click “+Add Role”
Step 3: Input a name and description for the custom role.
Step 4:
Click into the role you just created and set its permissions as needed.
See “Configuring Roles” below for additional guidance.
Editing Role Settings
You can edit a role’s name or description, view a role’s Role ID, or delete roles by hovering over the role and selecting “Role Settings”.
Configuring Roles
Overview
Each role allows or limits editing access to Coursedog functionality across the platform in each of the modules. In Curriculum, that includes:
Courses
Programs
Course Sets
Requirement Sets
Forms
Agendas
Requests
Settings
Drafts
Reports
Document Types
Campus Documents
Setting Permissions
Overview
You can configure Role-Based Access Control (RBAC) permissions for each role, for different features within each area of Curriculum.
For most functionality, permissions can be set to either “Allow” or “Deny”. However, a few permissions additionally have an "Allow If" (conditional) option.
If “Allow if” is selected, a list of conditions will need to be applied.
If “Allow if” is selected but no conditions are defined, that is the same as setting it to “Allow”.
Conditional Permissions
The following functions include a conditional (“Allow if”) option:
The Allowed Departments “Allow If” condition allows you to make role-based access department specific. Users can select which departments have editing and request changes capabilities on courses, programs, and requests.
User is Assigned to Department
If the condition is “Allow If User is Assigned to Department”, the user will have this permission so long as the user is assigned to the department, regardless of whether it is listed as a primary or secondary department in their profile.
Allows user to view the courses page as well as individual course details
View Course Integration Status
Allows user to see updates regarding whether or not the course has been synced with your SIS
Edit Courses
Allows user to edit courses directly in the UI without going through an approval workflow
If set to “Allow”, the user will see the “Edit Course” option under “Actions” when viewing a course
Recommended for super admin, admin, and department schedulers
Delete Courses
Allows user to delete courses.
If set to “Allow”, the user will see the “Delete Course” option under “Actions” when viewing a course
If someone with this permission attempts to delete a course, that will trigger a workflow; however, it is possible to have it be set up to autoapprove as part of the workflow
It is NOT recommended to add this permission
Share Courses
This is a deprecated permission; to share a course, you can copy and paste the link
Copy Courses
Allows users to copy courses when proposing a new one
If this is set to “Allow”, the user will see “Copy from Course” at the top of the screen when creating a proposal for a new course
Allows user to propose a new course or program or to propose edits to an existing one
If a user does not have this permission, they cannot propose a new course from the home page or propose a new [document type] in the course/program/document type inventories
Archive Requests
Allows a user to archive a request
Users with this permission set to “allow” will see an “archive proposal” option at the top of their screen when viewing a proposal
View All Requests
Gives a user the ability to view every request made at your institution, including requests/proposals that don’t pertain to them
Users with this permission set to “allow” will see an “All Requests” tab on the Requests Dashboard
Edit Requests
This grants a user the ability to edit ALL requests they have access to
If this permission is set to “Allow” but the “Edit Requests without Updating Workflow” is set to “Deny”, and the proposal is edited, the workflow will be automatically reset and all prior approvals disregarded
To restrict which proposals a user can edit, utilize the "can edit request/cannot edit request" (pencil icon) when assigning a participant to a workflow step
Edit Own Requests
Allows user to edit requests that they submitted
If this permission is set to allow and a user is viewing a request they created, they will see an “Edit Proposal” option in the upper right hand corner of the screen
Even if this and “Edit Requests” are both set to “deny”, the author will still be able to edit their own request IF a proposal is routed back to the author step (the logic being that if it is routed back to them, they need to be able to edit for the proposal to progress)
By default this permission is enabled for all roles
View Archived Requests
Allows a user to view archived requests
If this is set to “Allow” for a user, they will see an “Archived Requests” tab on the Proposal Dashboard
Delete Requests
Allows a user to delete a request
Users with this permission will see a “Delete Proposal” option when viewing a proposal
Edit Requests Without Updating Workflow
Allows a user to edit a proposal without updating its workflow; in other words, the proposal can continue its on-going progress through the workflow
If this permission is set to “ALLOW” and a proposal is edited, the user will have the option to determine whether or not the workflow is reset
If this permission is set to "DENY" and a proposal is edited, the workflow will reset and all prior approvals will be disregarded
Request Changes
Allows a user to propose changes to an existing course or program
When set to “allow”, users will see a “Propose Changes” option under Actions when viewing a course or program
Copy Requests
Allows user to copy an existing proposal when creating a new one
When set to “allow”, users will see a “Copy from Proposal” option at the top of the proposal
Allow Additional Requests For In Flight Requests
Allows a user to request changes when a proposal is already in flight for a course or program (see “Request Editing Permissions” below for more information)
If this is set to ALLOW, and multiple proposals are in flight, the second one will override the changes from the first one
Best practice is to set this to DENY for all roles
Setting this to DENY prevents overlapping proposals for the same course or program, which can lead to loss of approved changes due to conflicting proposed changes
Settings
Access
Description
View Settings
Allows a user to view settings
If a user can’t view the Settings page, they won’t be able to view/edit any of the menu options found under Settings
For example, if “View Settings” is set to “Deny” but “Edit Users” is set to “Allow”, the user won’t actually be able to “Edit Users” because they won’t have access to the option
View Departments
Allows a user to view departments
If this is set to “Allow”, the role will also need the “View Settings” permission
View Course Template
Allows a user to view the course template
If this is set to “Allow”, the role will also need the “View Settings” permission
View Program Template
Allows a user to view the program template
If this is set to “Allow”, the role will also need the “View Settings” permission
View Workflows
Allows a user to view workflows
If this is set to “Allow”, the role will also need the “View Settings” permission
View Roles
Allows a user to view roles
If this is set to “Allow”, the role will also need the “View Settings” permission
View Users
Allows a user to view users
If this is set to “Allow”, the role will also need the “View Settings” permission
View Form Routing
Allows a user to view form routing
If this is set to “Allow”, the role will also need the “View Settings” permission
View Terms
Allows a user to view terms
If this is set to “Allow”, the role will also need the “View Settings” permission
View Committees
Allows a user to view committees
If this is set to “Allow”, the role will also need the “View Settings” permission
View Health Checks
Allows a user to view health checks
If this is set to “Allow”, the role will also need the “View Settings” permission
Edit Departments
This allows a user to make edits to the settings of specific department or add a new department
If set to “Allow”, the role will also need “View Departments” and “View Settings” permissions in order to edit departments
Recommended for Admin only
Edit Course Template
This allows a user to make edits to the course template
If set to “Allow”, the role will also need “View Course Template” and “View Settings” permissions in order to edit the course template
Edit Program Template
This allows a user to make edits to the program template
If set to “Allow”, the role will also need “View Program Template” and “View Settings” permissions in order to edit the program template
Edit Workflows
This allows a user to make edits to workflows
If set to “Allow”, the role will also need “View Workflows” and “View Settings” permissions in order to edit workflows
Recommended for Super Admin and Admin
Update Workflows for Inflight Proposals
Setting this permission to “Allow” will give users the ability to click “Update Workflows for In-Flight Proposals” upon editing a workflow
If a user clicks “Update Workflows for Inflight Proposals” after making changes to a workflow, those changes will retroactively impact any in-progress requests
If a user makes changes to a workflow – but this permission is set to “Deny” for their role – they won’t have the option to update workflows for inflight proposals
Edit Roles
This allows a user to make edits to existing roles or create new roles
Ability to create an Allow If conditional, specifying the allowed roles the user is allowed to edit. This allows a restriction where a user can edit Role X and Y, but not edit Role Z. If a user has restricted edit access to roles, they will see only a subset of those roles appear when they visit the Settings → Roles page
If set to “Allow”, the role will also need “View Roles” and “View Settings” permissions in order to edit roles
Recommended for Super Admins only
Edit Users
This allows a user to create, delete and edit Users
If set to “Allow”, the role will also need “View Users” and “View Settings” permissions in order to edit users
Allows user to reset passwords for other users, provided the user has requested a reset
Recommended for Super Admins only
Edit Form Routing
This allows a user to make edits to form routing
If set to “Allow”, the role will also need “View Form Routing” and “View Settings” permissions in order to edit form routing
Edit Terms
This allows a user to edit terms If set to “Allow”, the role will also need “View Terms” and “View Settings” permissions in order to edit terms
Recommended for Admin only
Edit Committees
This allows a user to edit all fields in a committee. Note that the "roles allowed to edit committee" provides additional control to what roles can edit a committee. A user must have a role with the "edit committees" permission and a role that is specified in "roles allowed to edit committee" to edit the committee
If set to “Allow”, the role will also need “View Committee” and “View Settings” permissions in order to edit committees
Edit Committee Members
This allows a user to edit only the members + member workflow permissions in a committee. Same rules apply for "roles allowed to edit committee"
If set to “Allow”, the role will also need the “View Settings” permission in order to edit committees
Edit Workflow Notifications Settings
This allows a user to edit workflow notification settings
If set to “Allow”, the role will also need the “View Settings” permission in order to edit committees
Edit Schoolwide Saved Views
Allows user to access the Schoolwide Saved Views dashboard and edit Schoolwide Saved Views
If set to “Allow”, the role will also need the “View Settings” permission in order to edit committees
If set to DENY, user will be redirected to the homepage upon clicking Settings > Schoolwide Saved views
Allows user to view "reports" in the left nav panel
If set to “Allow”, users will be a handful of prebuilt reports, including Program Changes, Invalid Workflow Users, and Courses/Programs Out of Sync with SIS
View Course Not Taught Report
If set to “Allow”, users will see a listing of courses that have not been scheduled in a specific time period by a department
If set to “Deny”, users will see the option to view this report; however, they will get an error message if they click it
If set to “Allow”, the “Campus” option will appear in the left-hand navigation
Edit Campus Documents
This allows a user to edit campus documents
In order to edit campus documents, “View Campus Documents” will also need to be set to “Allow”
Reset Workflow Permissions
Permissions are used to control what options a user has when they edit a request. Learn more about reset workflow permissionshere.
Request Editing Permissions
Changes" and "Allow Additional Requests For In Flight Requests" permissions are set to “Allow” and/or “Deny”.
Note that setting “Allow Additional Requests for In Flight Requests” to Deny will have no impact if the proposal is for a different revision. In other words: If the first proposal is for a revision that has an Effective Start of Jan 1, 2025 and then the second proposal is for the same course but has a Effective Start of Jan 2, 2025, that second proposal will be treated as a new revision (and the user will be allowed to submit it).
Setting for “Request Changes”
Setting for “Allow Additional Requests for In Flight Requests”
Result
ALLOW
ALLOW
The user is able to propose changes to the given course/program, even if there are existing proposals in-flight.
ALLOW
DENY
The user is able to propose changes to the given course/program, but ONLY if there are no existing proposals in-flight.
DENY
ALLOW
The user is NOT able to propose changes to the given course/program (the second permission is a moot point in this scenario).
DENY
DENY
The user is NOT able to propose changes to the given course/program.
Additional permissions can be set for different roles at the field level.
In other words: within Curriculum forms, each field can be configured to control which roles can see it.
Visibility
To limit which roles can see a field on a form:
Navigate to the template or form.
Select a form field.
Check the “Visible” box to ensure the field is visible for some or all users.
Click the dropdown titled "Visible for all roles".
Select the user roles that should be able to see the field.
Editability
To limit which roles can edit a field on a form:
Navigate to the template or form.
Select a form field.
Check the “editable” box to ensure the field can be edited by some or all uses.
Click the dropdown titled "Editable for all roles".
Select the user roles that should be able to edit the field.
Hard-Coded Logic
There is some hard-coded logic in Curriculum Management that is tied to prebuilt roles.
Roles Visible Only to Coursedog Users
The student and Coursedog roles are non-editable (invisible) to anyone who doesn’t have the Coursedog role.
Unless the user has the Coursedog role, they will be unable to see these roles and configure their permissions in Settings > Roles.
If you wish to change any related configurations and don’t have the Coursedog role, please reach out to your Coursedog Customer Success representative.
