[Commons] Restore dynamic subaccount-based groups to Canvas Commons

The June 12 release of Canvas Commons (Commons Release Notes (2016-06-12) replaced the previous subaccount-based sharing permissions structure with a new "Groups" model. These Groups require manual management, either by a campus administrator or an individual designated as a Group Manager.

 

The previous subaccount-based sharing model allowed instructors to more dynamically share resources with their departmental colleagues without any need to identify and individually designate each one as a group member. At an institution as large as ours, with over 40,000 active Canvas users, manually managing groups quickly becomes an unsustainable process.

 

Although the new groups model provides some useful ways to support cross-departmental collaboration and resource sharing, removing the ability to dynamically restrict access to Commons resources by subaccount is overall a significant downgrade to Commons' usability and functionality. The subaccount-level sharing should be reinstated, complementing the new option to manually create and manage Commons groups.

Added to Theme

25 Comments
admin_brake
Community Participant

Yes, subaccount-based sharing permissions structure needs to be an option.

Colorado State Univ

kmcgee
Instructure Alumni
Instructure Alumni

I want to thank you all for sharing your feedback on this functionality request. Anytime we build new features into our products our aim is to improve your experience. It's clear from your comments that while groups added increased flexibility for inter-institutional sharing, removing sub-account functionality has been detrimental to the sharing process. I also appreciate the comments on hierarchical structure of sub-accounts in Commons. We are gathering information on this request so please continue to share your use cases of how your institution is sharing resources. Thank you again for your passion for our products!

Kate McGee

Canvas Commons Product Manager

MLentini
Community Participant

Thanks for the update on the process, Kate.

Indeed, the new customizable sharing is valuable. The issue is that losing the original sub-account sharing broke both sub-account-based sharing for those of us rolling it out, and also broke automated group creation (since the API for this doesn't exist yet).

In our case, we were building automation for both Outcomes and Commons on the same structure. Our plan was to have faculty assigned to the appropriate sub-accounts based on the courses they were scheduled to teach. The idea was that they could share materials with the course, a whole department, the college... whatever level they were comfortable with or felt was appropriate. It would have allowed department repositories down to the course level. So a sample hierarchy:

  • All of Instruction
    • Academic Division (Arts and Humanities)
      • Department (English)
        • Class (English 101)

The same would be true of outcomes.

Being able to build this on sub-accounts means one set of scripts to maintain for automation, so while the API for groups would be nice, it still means a separate dev request, and more time to get it built.

Hope this use case is helpful.

Marc

millerjm
Community Champion

Wow, I just found out about this change today.  We couldn't figure out why a program manager didn't have a subaccount listed to share to.  Finally figured out that groups had to be made manually! 

This feature request is extremely important to my institution and my staff.  We like that we are able to manually create ad-hoc groups and grant access but having to do this for all of our departments and courses would be a huge step back!

Our subaccount structure is set up like this:

  • Career Programs
    • Information Technology
      • CGS
        • CGS1060C

The classes all live in CGS1060c.  So sharing with CGS1060c would allow all faculty teaching CGS1060c to access the resources.  Sharing with CGS allowed resources to be shared with a wider audience in that department, and they still could share with their entire department or college if desired.

This allowed them to also not clutter up other people's commons area with stuff completely irrelevant - a sociology prof has no interest in seeing computer science content.

This structure was also very helpful for my staff who could share publisher content to the commons area for just one class and make it available to all faculty teaching that course. 

Allowing the subaccount structure and membership to be used for commons again would really allow us to use it to it's fullest potential.  We have 3 instructional designers who support over 700 faculty.  Having to manually create commons group and enroll users just isn't logistically possible for us.

millerjm
Community Champion

Kate McGee​ , Thank you for your thoughtful reply.  I realize that you have a lot of projects going on and this response was probably not expected, but could you please give us a timeline of when you think this change will be made?  

We have just finished our migration and were about to start training a wider audience about Commons.  It would allow my institution to at least plan on when to start increasing adoption of Commons because we don't have the staff to add groups and users manually for our institution.  (Should we do training in August when faculty return to campus or wait until later in the fall term?)

Thanks again!  Smiley Happy

SHEBENE
Community Champion

In the interest of sharing a use case, here's our structure and why it's extremely important to have sub account sharing.

Instructional Unit (contains all schools)

  • High Schools (contains all HS)
    • "Specific HS"
      • Live Courses
        • Mathematics (all of "Specific HS's" live math courses are here)

So, a math teacher at "Specific HS" could (with sub account sharing) share with their peers at the same school without any other teachers at the school having Algebra I get mixed in with their Chemistry content. Additionally, a teacher or admin could share content intended for the whole "Specific HS" without cluttering the entire district. We're a huge K12 with hundreds of schools and thousands of sub accounts. The potential for extraneous content muddying the waters is great. Manual groups adds a great potential element where we can have several HS math teachers be in the same group and share across school boundaries but the most frequent use would come from sub account sharing.

Thanks for working on this.

ccalderon
Community Champion

Thank you so much for listening to the Community and putting this out for a vote! This change to Groups caused us to scrap our plans for a Fall release of Commons to our campus, as we would have had to create Groups from scratch using a laborious workaround. Thus, we are of course hoping to see sub-accounts added back in as an option sometime soon. Both methods have their merits, and I hope they can co-exist happily in the Commons world, just like these guys:

Happy Friday!

grogne
Community Participant

Connecting sub accounts to commons groups is a must. Please restore this functionality! In our K-12 district this is how we are sharing resources from the admin level to the campus level. Teachers are starting to come back and since the groups were initially created with sub-accounts, the materials are there, but teachers cannot access the resources, because they are not in the group if they didn't click on it before the switch happened. I have to manually add one at time. I was hoping to at least people able to paste a list of emails at one time, but I have to add one at a time and if they haven't clicked on Commons yet and authorized it, I can't find them. Since the sub-accounts are linked to our SIS, the groups would be auto updated, even if they haven't authorized yet, so when they click on Commons for the first time and authorize they can automatically see the correct group for shared resources. Unfortunately, this fix probably is not going to come fast enough for me and I am going to have to manually add 1,000 teachers to their correct Commons groups by next week.

Renee_Carney
Community Team
Community Team

The Radar idea stage has been removed from the Feature Idea Process.  You can read more about why in the blog post Adaptation: Feature Idea Process Changes.

 

This change will only impact the stage sort of this idea and will not change how it is voted on or how it is considered during prioritization activities.  This change will streamline the list of ideas 'open for voting', making it easier for you to see the true top voted ideas in one sort, here.

SHEBENE
Community Champion

This reminds me that it's been two years and we still don't have this... Smiley Sad sad face indeed. A year ago this summer it sounded like it was going to be added during InstructureCon time and still nope. This is re-instituting code rather than necessarily creating it from scratch. Please add this to the list of things to develop.