Enrolment via automated SIS script/cross-listing issue: use Section rather than Course?

[a_craik]

Not sure if this is a question for Canvas Developers, Canvas Admins or LMS Migration Strategies, so it's a shout out to you all here!

We're into a 2nd year of Canvas now, and have had a working SIS integration from the get go. The daily automated SIS import will:

• Create new Canvas courses (for any courses that have been added into the SIS) and put them into their designated sub-accounts and correct terms
• Add any new enrolments for staff and students onto Canvas courses

We've got some real issues where Canvas Sections are being cross-listed. If the Section from Course A is cross-listed into Course B, and then a student enrols on Course A in the SIS, once the SIS import has run then that student will appear in Course A in a new section (also titled "Course A"). This means that cross-listing a section is only really possible once the last student has been enrolled (and can you ever be sure who that last student is??). 

I'm sure it doesn't have to be this way - enrolment data should be dynamic and follow the cross-listed section rather than landing in a new section in the original course, right?

Here's my guess as to what's happening (in layman's terms as I'm no programmer):

1. SIS import initially creates a new Canvas Course
2. SIS import adds enrolment data to Course (which automatically creates a section of the same title as the course - just like when you manually create a course)

Due to the focus on Course (rather than Section), when the SIS imports new enrolment data for a Course that has already had it's section cross-listed, the original Course reappears (as it will have been hidden by cross-listing) - it doesn't have a section though, so as per no.2 above, a section is automatically created for the new enrolments.

So here's my guess as to how it should be:

1. SIS import initially creates a new Canvas Course and also creates an empty section with a Section ID
2. SIS import adds enrolment data to Section

Now the focus is on Section, so when the SIS imports any new enrolment data for an existing Course that has already had it's section cross-listed, the new enrolment data should be pushed to that cross-listed section.

Is this:

1. Correct logic?
2. Similar to how your integrations work?

Many thanks to anyone who can contribute - arguably the best thing about Canvas is it's community

Cheers

Adam

[tdelillo]

I can't speak to the exact details of how info flows from the SIS to Canvas, but I CAN say with certainty that enrollments should be pushed to sections, not courses. We use a lot of cross-listing, and even if Section A is cross-listed into the shell with Section B, new enrollments in Section A go to the correct place - the Section A section that is living in the Section B shell (if that makes sense).

It would be helpful if you specified which SIS you're using (or is it homegrown?), so the Community members with the deeper knowledge of that system and how it integrates with Canvas can weigh in.

[a_craik]

Thanks Tracey, it's really useful to hear that your integration allows for 'roaming sections'!

Our current SIS is indeed home grown, but there is a new one due imminently called SITS (by Tribal). I believe SITS is quite big in the UK.

I also wonder whether understanding the value of targeting sections in enrolment (over courses in enrolment) could be a wider issue for the UK users, due to the way we align Canvas courses to what we define as "modules" (and you can imagine how confusing that is given Canvas courses are structured by a tool called Modules!).

[ben_hudson]

Hi  @a_craik ‌,

I would suggest you talk with your Technology Department or whoever setup the SIS Imports because I just ran some test in my beta environment and I'm not receiving the same results as you. When I create a course with our without a section, cross-list that section into another course and then import a new user into the original cross-listed course/section my user only shows up in the Course/Section that the original Section was cross-listed into.

So I had Course A/Section A I cross-listed this into Course B, so I now have Course B/Section A.

Course A/Section A then disappeared.

I then added a new student using the SIS Import into Course A/Section A and the student only appeared in Course B/Section A while Course A/Section A did not reappear.

The only way I can get Course A to reappear is by adding another section, so depending on how your imports are setup a new section may be being built causing Course A to reappear. 

I do agree with you that your "how it should be" example is a better route because things are more defined and this makes things easier to control.

Hope this helps!

Thanks,

Ben

[ColinMurtaugh · Accepted solution]

Hi Adam --

As Tracey and Ben suggest above, you're on the right track with the idea that you should be creating sections and feeding enrollments into those explicitly.

Here's what's happening: when you feed enrollments into a course (by specifying a course ID rather than a section ID in the enrollment data you send), if there is no section under the course, Canvas will create one for you and place the enrollments there. This is why you're seeing a new "Course A" section appear under the Course A course after the original Course A section had been moved into Course B.  When Canvas received subsequent enrollments destined for course Course A, it found that there was no longer a section under Course A, so it went ahead and created a new one for you. 

This is because enrollments must always live in a section, not directly under a course. For all courses that have people in them, there will always be at least one section. 

As the others have mentioned, explicitly creating sections and targeting enrollments to them will solve your problems!

--Colin

[a_craik]

Thanks everyone for contributing - I had a meeting with our integration manager last week and he's completely on board with what we now need to achieve 

The fun part, as always, will be how we get there! If we were year zero, pre-launch, this would be a doddle. Alas we are two years in with 3 years worth of courses already generated via the SIS integration... and those courses all have sections that have been generated by Canvas rather than by SIS, so all sections have titles, but non have IDs. Section IDs can be added to sections manually via the UI (i.e. going into one course at a time), but it doesn't seem that they can be updated with IDs via a SIS import (see sections.csv).

As our SIS/Canvas integration uses the zipped CSV approach, I'm not sure at this point whether it's possible to add IDs to sections via this method either (as it's also CSV based). I will investigate and repost (unless someone in the know posts before I do!).

Cheers

Adam

[ben_hudson]

I would suggest prepping and waiting to implement the changes at the start of the next school year. Your situation reminds me of when I came on board with my school district, the district was not building unique SIS ID's for courses and sections, which would have caused issue in later years. So now we do a combination of course information and school year. A course SIS ID example we developed is: 405-506200-1718YR-7625072 (BuildingCode-CourseCode-SchoolYearAndCourseLength-InternalStaffID) while a section SIS ID example is 405-506200-1718YR-7 (BuildingCode-CourseCode-SchoolYearAndCourseLength-CourseSection)

I would suggest coming up with some standard to follow like that so it is easy to change each year and you won't have to worry about duplicate SIS ID's.

Hope this helps!

Thanks,

Ben

[a_craik]

I completely agree Ben - it would be ideal if we could wait to apply the new approach and not have to do apply a fix to data retrospectively. Unfortunately our SIS is somewhat ahead of the game and already contains courses and enrolments for the 2018/19 academic year... so these already exist in Canvas. Even more surprisingly, due to the disparity between real world teaching times and SIS dates, some of those 18/19 courses will already be in use - so we can't even take a 'delete and replace' approach!

[pklove]

You won't be able to add the missing SIS IDs with a SIS import as they all need the SIS ID of the object you are manipulating.

It would quite straightforward to do it with the Sections API (Sections - Canvas LMS REST API Documentation).  One call to get the course's sections and then another to add the missing SIS ID.

[a_craik]

Thanks Peter - spot on advice that mirrors exactly what Canvas have advised me last night! We'll be adding the missing IDs via GET and PUT calls, then changing the SIS integration so it points enrolment data at the sections rather than the courses.

Although we're yet to action this, technically this has resolved the initial question... so I'd like to continue dialogue on a related theme if possible (although I accept if it's more proper to start again under a new question!).

During the investigation of the original query and dialogues between Canvas, our Integrations Manager, and your good selves on here, it's become clear that we have an opportunity to move away from the zipped CSVs style of automated SIS integration (which is running daily) and instead change to what I'll call a 'live API connection' (i.e. changes to course/enrolment data in the SIS triggers a RESTful API call without the need for CSVs). This would mean that when a change is made in the SIS, said change will be reflected in Canvas much quicker than it does with a daily CSV import.

I would imagine though that this might actually be a bad approach when it comes to the inevitably huge volume of data that is generated all at once in the SIS for each new term/semester (my concern is about overloading). So now I'm thinking if this might be the "ideal" setup:

1. For specific times when the SIS generates a large volume of data at once (i.e. new year "roll-over"), SIS integration should use the zipped CSVs approach as a robust method of importing bigger data
2. For all other times (i.e. the inevitable smaller amendments during the course of a term/year), the SIS integration should adopt the 'live API connection' approach

What do you think? Is this how your integrations are set up?

Cheers

Adam