We would love this feature. Our most time consuming problem is instructors who request a cross-listed course in D2L and uploaded items to one (or both) of the original courses, either before or after the cross-listed course is created. It's extremely difficult for us to identify and correct these situations.

At Wake Forest, we're transitioning to Canvas and allow instructors to activate courses through the web, based off of loads created by the Registrar.

We are experiencing an issue when instructors "cross list" courses in Canvas. The unique identifiers that associate the course with the users that are available via the loads are not able to predict the values and still allow access to students from both sections and the instructor. The custom_section_id has a different value for both of the initial courses at the beginning (for an example, these would be courses A and B and their respective ExternalCourseIDs would be 1234A and 9876B). The instructor enters either one of these courses and selects the option to merge. This creates and sends a comma-delimited value of the two courses' SIS IDs (1234A, 9876B) in the field that was pre-selected as the unique identifier in Ares. This creates a unique situation where a new course is created in Ares (with no items, so the instructor is concerned), but then the students have been pre-registered using the pre-existing unique identifiers, so they are still seeing the first two courses, not the merged ones, if they access Ares through the web, instead of going into the Canvas link. If they do use the Canvas link, it will successfully enroll them into the new course, with its comma-delimited unique identifier, but they're still enrolled in the initial courses and the loads will continue to enroll them in these courses and re-create the courses, even if we remove the initial ones, so the students and instructor are not confused by still seeing the pre-merge courses. We discovered an alternative value, the sis_id, also passes this unique identifier and will retain the value of the course that the instructor deems the "alpha" course between the merged courses. So, for our example, the unique identifiers will pass 1234A for users in course A and for the instructor, which means the instructor continues to see whatever items were in that course to begin with and students in course A can continue unaffected. The students in course B, however, now pass a different value in that field through Canvas, so the students in that course will only be enrolled into the updated course if they use the Canvas link (which we don't require they use, since we want to allow them direct web access). Even if they do go in and use the Canvas link, they'll continue to be simultaneously enrolled in both 1234A and 9876B, because the Registrar loads still pass the values, regardless of the action the instructor takes in Canvas. It gets worse: as the load jobs are used to automatically adjust enrollment for students as they add/drop, even if we forced students in course B to go and manually enroll through Canvas, by the next morning, they'll be removed, because the load is still passing enrollment as some students go to 1234A, some students go to 9876B, and the instructor as teaching both both. So students from course B who have been added by Canvas to course A, will be removed, because they don't appear as enrolled in the loads.

I like this idea. I think the way I was picturing its implementation was to designate one course as a master template and have a list of courses that would update as items are added/modified/deleted in the template.

If two courses have been merged in the course management software (e.g. Blackboard), this would allow staff to more easily correct it on the Ares side.