cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jcarter1
Community Participant

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.

Thanks.

15 Replies
Stef_retired
Community Team
Community Team

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  @chofer ‌'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.

jcarter1
Community Participant

Awesome! Thanks a lot.

dwillmore
Community Champion

  • 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.

jcarter1
Community Participant

Thanks so much David. This is extremely helpful.

natalie_norton1
Community Champion

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...

baxl
Community Contributor

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?

dwillmore
Community Champion

You are most welcome, and this was a great question.   I am enjoying the replies as wwell.

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!