Best practices for managing LMS permissions
As our university grows, we are finding some challenges discerning who should get what level of Canvas permission.
Some situations may be fairly straightforward: teachers get teacher permissions; however, what about all of the other 'players' such as the Dean, the department chair, the vp for institutional effectiveness, and etc.? Some need greater access, others like to tinker.
Can anyone share a Canvas permission policy that the use at their institutions? I have found a good deal of technical how-to's but can't find anything on policy.
Hello, @jcarter1 , thanks for initiating this very useful discussion! While I don't have a policy document to share with you, I would like to call your attention to @Chris_Hofer 's blog post on a custom role he created for his school: https://community.canvaslms.com/groups/admins/blog/2017/02/17/master-courses-and-our-custom-viewer-r... He describes an innovative way to use roles and permissions to manage how the integrity of course content is preserved.
I'm hopeful that others will spring forward with their contributions.
- Root Account Administrator - only the LMS administrator, assistant LMS administrators, and online department dean
- Root Account Helpdesk Administrator (modified account administrator role)- only for our Help Desk
- This prevents the Help Desk from doing much in a course but gives the crucial 'add user' right so that students in Canvas that were not properly enrolled in a Canvas class via our SIS import can be added quickly. We prevented the removal of students from a course because many on the Help Desk also take classes here and we wanted complete transparency for their actions. The Help Desk folks cannot masquerade. (We did not want to enroll as a teacher and then remove their ID after looking at course information.)
- Account Administrator at Sub-Account - If dean requests access, which they have not, I would give them account administrator at their division sub-account. If a department chair requests access, which some have, I give them account administrator access at their department sub-account.
- Obviously, we have created sub-accounts at the division and department levels and recently have duplicated that structure for our online courses with 'Online' being added to the sub-account names.
- Teacher2 (modified Designer role) - We created this course role to add people with full teacher access that does not add the teacher's name under the course name when viewing courses. We rarely use this now, and it may be removed.
- NoConversation (modified Student role) - This was created for a special student case and has since been removed. It removed the ability to use the Conversation tool for the student.
At first, we used the Sub-Account role to limit our deans and chairs from complete account administration privileges but decided there was no need to do so.
I have attached our permission settings below for both course and account permissions.
If anyone sees anything that has a potential to create problems with the way we handle our roles and permissions, please let me know with reasoning behind the concern. I honestly don't know what I don't know.
Hi - we don't have a policy document but I can give you a rough overview of the custom roles we have set up:
For account roles:
- Account admin - only in TEL dept
- Course admin - administrator added at sub-account level (Faculty or dept) with reduced permissions. In addition they are added at account level as a 'masq admin' - this is a role with two permissions, to 'become' a student and manage SIS data, as they does not work at sub-account. This then works in the relevant sub-account. It is a bit strange but the only way we could get them those permissions to work in sub-account!
- Head of Dept - applied at sub-account. Limited permissions but enables them to see course content for courses in their dept and adjust a few settings
- Programme Leader - applied at sub-account. Like Head of Dept, but slightly more limited. Main purpose to see content in courses without needing to be enrolled on them all.
- Support - for student support. At account level - can masquerade so they can support students
For course roles:
- External Examiner - added to courses to view content, assignments and feedback. Cannot change content
- Student observer - our students are enrolled via SITS, but occasionally a student needs access to another course they are not actually taking. Should basically be read only but not fully tested. May be some quirks!
- Observer - using this for a slightly different purpose to add additional staff who need to see course content but not teaching. Trying to enrol them this way to try and minimise notifications they do not need.
Hope that makes some sense! We always find permissions need a bit of tweaking as they often have unintended consequences...
This is great information! We have teachers and co-teachers across the world and often have to adjust roles to fit the business model. Thanks for sharing!
That looks like a great model. Are you able to share the role permissions you created? I really want to see what you did with your sub-account permissions for head of department and program manager roles.
I think your external examiner course role sounds better than what I am currently doing for requests like that. Forgive me, but I am stealing that one.
Would you be willing to explain in what type of instance you need to use your student observer course role?
Of course! They are not perfect as we keep finding unexpected quirks so keep tweaking them. For example today we found that someone applied at subaccount faculty level cannot see the subaccount menu item, so they can't go down to the lower levels (eg faculty > dept). So, for example, if they wanted to put up a global announcement or run reports just for one dept in their faculty they can't. Awaiting feedback on which permission might need changing!
With the HoDs and PLs it is a bit of trial and error to give them the right access. Feedback at the moment seems to be that this is about right, but we have implemented relatively recently.
Student observer - for example we might have a postgrad or PhD student who would find it useful to see content on an undergrad course, or we might have a student looking to change module and wants to have a look. Basically trying to create a way to give read only access to a student who is not enrolled on the course in SITS.
Hope that helps!
Thank you so much. That trial and error thing is a big reason this is such a great question posted by @jcarter1 !
We too had issues with using the sub-account admin role and found that using the account admin role posed little risk when used at a sub-account level. Give it a try.
We added a custom role called Teacher Copy Only. The role is based on Teacher so that the teacher can import from this course to their own but we have limited the maintenance access as much as we can so that there are very few changes they can make in the course.
dgrobani, No problem. The role is based off Teacher. The only permission that is enabled is Manage All Other Course Content. We had to enable that one for import to work. We created it for those courses where you are afraid of people deleting.
There are a few issues you can't get around.
1) They can change modules. They can't delete the base content but they can make changes to the modules.
2) I discovered the hard way last week that a teacher can import into the course. Had one import from the course to itself instead of to her own course.
I keep watching release notes hoping for a true read-only role but haven't found it. Our implementation team helped us set this up 3 years ago so if some has a newer idea that would work better, I would love to hear it.
dgrobani, in addition to the excellent solution tross has presented, I wanted to call your attention to @Chris_Hofer 's implementation of a custom "viewer" role, as described here: https://community.canvaslms.com/groups/admins/blog/2017/02/17/master-courses-and-our-custom-viewer-r... (it's already mentioned upthread, so this is icymi)