Showing results for 
Show  only  | Search instead for 
Did you mean: 

In Permissions, Separate Manage (add/edit/delete) courses into 3 permissions

In Permissions, Separate Manage (add/edit/delete) courses into 3 permissions

This idea has been developed and deployed to Canvas

Please change, nn Account Roles the  "Manage (add/edit/delete) courses" from a single setting to three separate settings.



Manage (add / edit / delete) courses


Should become:

  • User can Add courses
  • User can Edit courses
  • User can Delete courses


One reason for this request:

This would allow you to set Sub-Account Managers (or other roles) to having only the permissions needed for that role instead of none of them or all of them. For example, the ability to add a course but not to edit or delete a course.


Note: There is this one as well, In Permissions, Separate "Manage (create/edit/delete) course sections" into 3 permissions  (this is for the same thing but with sections and not courses)


Comments from Instructure


We have exciting news about the first phase of the Priority: Granular Permissions‌.  The New User Interface is included in the Canvas Production Release Notes (2018-07-14) .  Go check it out!

Community Champion

I'll support this with a up vote once open.

Community Champion

This idea is now open for voting. Smiley Happy

Community Participant

Thanks again for creating all of these, Susan!

Community Participant

Rationale: This feature would give greater access to our subaccount admins.  Right now we do not enable this because there is the possibility of accidental deletions.  If the permissions were unbundled we would be able provide subaccounts with the ability to add courses such as workbench sites for new faculty or even create workbench sites for new courses in development. 

Community Participant

Rationale for Stanford: This is the most important permission separation of all. We have run into the situation where instructors expect a TA or admin to run their course, therefore needing to be able to publish the course. However, this also means they can delete or conclude a course. Due to the severe consequences of deleting or concluding a course by accident, we want to restrict that to system support staff, while still allowing instructors and TAs the permission to publish courses without needing help from support.

Community Champion

If the button is there, they will click it!  :smileyshocked: And then deny that they clicked it and wonder why whatever bad thing happened!!! 

We need to be able to give the following permissions: 

Publish course - TA, teacher, program managers

Conclude course - administrators only since instructors don't know the implication of concluding a course (not having access to much of the data)

Add course - this would be program managers and associate deans and departmental instructional support staff

Edit Course (dates, title, etc) - only certain sub-account admins and possibly program managers in certain departments who teach odd-term classes. 

Delete Course - administrators only

And, while we are on the Course permissions, this one is pretty scary :smileyalert: and our instructors have actually asked us to take it away: 

Reset Course Content - administrators only

Community Member

Excellent points! We are currently transitioning to Canvas and I was surprised to learn that course publishing is tied to the ability to add/delete courses. Coming from Moodle, this bundling of permissions has been a very difficult adjustment.

Not applicable

We (University College Northern Denmark) also wants separate permissions options here.

In this permissions is the "student view" button which is a great feature for teachers. But to get this feature, we give teachers the rights toReset and Permanetly Delete course - giving some unfortunate situations for our teachers.

We therefore hope that you will develop a button (a permission) to turn the Student view on, but deselect all of the other functions in this permissions.


I understand the reasons why it would be helpful to separate out the delete permission. I'm looking into how big the effort would be and will post an update here.


Community Member

UW-Madison has a use case where we create new courses for instructors occasionally (sandbox courses, non-timetable/SIS courses, etc.) We have student workers who assist with that process -- it's not automated currently. We'd like to allow those workers limited permissions, such as the ability to add a course for someone but not edit it or delete it.

Community Champion

Does this permission also give the "Conclude this course" button?  We just spent 2 hours fixing where a faculty member concluded a course.  Unconclude does not make those users active in the course again, so we had to do another SIS import in order to make all of the users active in the course again so that they would show up in the gradebook. 

When we pointed this out to the instructor, she didn't remember clicking on it 3 days ago and since these classes had 3000 students combined, it affected a lot of people. 

Another instructor clicked it last week because he wanted the course to go away from his list in Canvas, not knowing how it would affect his course. 

Community Participant

We perform a lot of these actions through our registrar's feed (i.e. concluding and adding courses), and it would be great to be able to make the action unavailable in Canvas, rather than hiding the buttons with custom CSS/JS. Right now, we can't prevent users from performing certain actions because all of the permissions are bundled together! Separating Add/Edit/Delete is a start, but a more nuanced permissioning scheme like the one proposed here would really help get us where we need to be.

Community Member

add/edit need to be split for the same reason I outlined in

We need flexible structures to allow wide usage and less time fixing problems caused by wide-open permissions.

Community Champion

 @anf107  could you please copy/paste a modified copy of those reasons so that they stay together with each of these ideas?

I know they all seem about the same but the product team needs to be able to justify the resources that they will need to put into this, and the more that we can spell out these use cases, the better.

Thank you!


Not applicable

Hi  @millerjm ​

I think that 'end the courses' is part of this permission.

We also just had the same experience with a teacher who accidentally clicked 'end the courses'.

Community Champion

You are right,Separate Manage (add/edit/delete) courses into 3 permissions doesn't really make this permission as granular as many institutions need.

My suggestion is to update this permissions change to be more granular than just "manage courses".  There are several of these functions that we might give to a program manager for their department but not to a regular faculty member.  We already have these settings for Don't let teachers rename their courses in the Account settings (not in permissions)

Conclude this Course Button (Yes or No)

Reset Course Content Button (Yes or No)

Modify Time Zone (VIEW ONLY or MODIFY)

Modify Dates Start and End Dates and participation settings (VIEW ONLY or EDIT or NONE)

Language (VIEW ONLY or MODIFY)

Visibility Settings (VIEW ONLY or EDIT or NONE) - would include all of the settings in the screenshot below:


Community Contributor

I just went through this same u=issue with Canvas Support.  I want my department chairs to have the ability to edit a course, but not necessarily add/delete the course.  We use APIs to handle the adding and deleting. 

That's for bringing this topic to life again..



This idea will be considered, along with several others, when we engage in a deep dive and audit of our permissions in Canvas this coming summer. If you are interested in participating in this discussion, please shoot me an email:​ As we consider all of the possible permission granularity requests (see Canvas Permissions and Granularity Feature Ideas), we will be considering a number of different factors, including the COST and the BENEFIT of making a change:


What extra work will be required in the Canvas app if we break out this permission?

What is the level of engineering effort required to implement this permission split?

What will it mean for us to support this new permission indefinitely as we add new features?


What use cases would this granular permission support?

How many of our existing customer require support for each of those use cases?

These are not the only considerations, but I mention this line of reasoning because between now and the summertime when we start to dig deep into this topic, voters on this thread have a big role to play in persuading us of the potential benefits to admins and users. Your votes and comments will help us to measure the percentage of our customer base that will actually use the permission split, if implemented.

Bottom line: Keep those votes, comments and use cases coming! They will be very valuable when it comes time to decide which requests to prioritize.

Community Champion

We need some support for our case that the permissions available in Canvas are not sufficient for our needs.  Above is the update that Allison Weiss posted to many of our feature ideas.  She is asking for use cases for granularity and we really need to justify each and every one.  I made a document to track discussions and feature ideas related to permissions: 

Canvas Permissions and Granularity Feature Ideas

This is the sort of information that would assist in getting these changes made during this permissions audit.  This information would need to be added as comments to the individual feature ideas, and if it needs to be pasted to more than one, then please do that.  I know it's tiresome to post the same thing again and again, even though someone else has already done it, but they need to see that it's not just 5 people with these issues!  We haven't gotten much traction because we haven't had enough use cases posted but my document above seems to have gotten some attention.

  • What has the current user permissions "bundling" and lack of granularity cost you in terms of support and functionality?
  • What permissions have you HAD to grant to someone simply to allow them to be able to do their job, that you would have rather NOT given?
  • What permissions have you had to DENY giving someone because it gave them access to something that you could not due to security, concern about causing trouble, etc.?
  • What other qualms do you have about things?
  • What things have cost you more in staff hours because of denying access to someone, means that your department had to research, do work, etc, on behalf of a user that would have been able to do their work if the permissions were granular?

Thank you!


I'm also tagging  @kona ​ and cms_hickss​  since they have been so involved in getting attention to these feature ideas. 

Community Team
Community Team

Greetings, Partners on Permissions

Thank you for the time, energy, experience, and knowledge you have put into these threads.  The granulated permissions threads have been open and gathering information for almost a year now.  This extra time has allowed our team to collect important feedback and perspectives.  Each of the permissions threads contain valuable stories that will help inform development if/when a project is allocated for.  Having worked with Allison on these, and now working with Matt G., I know that the product team is sincerely interested in improving permissions, however the magnitude and impact of such a project does not make it one that is easy to squeeze in.  We will be archiving these permissions threads for now.  Archiving these threads does not mean they are forgotten; they are set aside, while they are inactive projects on our roadmap.  The ideas are monitored, so you can continue to add your examples and use cases to the dialogue.  Please follow this thread to receive updates when they are available.

Again, thank you for the rich conversation!