TL;DR We're announcing the formal deprecation of our sections data model and APIs.
Now onto the longer explanation.
What are sections?
Sections have been around since the inception of Edlink in order to address user experience differences between Canvas & Schoology and the rest of the systems that we integrate with. In particular, both Canvas and Schoology have features called "cross listing" and "linking sections", respectively, that create some interesting effects for teachers. Essentially, teachers can link sections (what Edlink & OneRoster both refer to as "classes") together to save time on redundant activities like assigning homework.
The challenge for developers is that when assigning work via the native APIs of these systems, the "linking" behavior persists and creates some not-so-easy-to-predict effects for the developer.
Our original solution back in 2020 was to create a single Edlink class for all of the LMS sections that were linked together in order to establish consistency across our APIs. We then created a new data model (what we called "sections") in order for developers to be able to differentiate between the original classes, if needed.
This solution was confusing for both developers and teachers.
When is this change happening?
Starting on or around July 1st, we will begin to transition Canvas and Schoology connections to use the new sync mechanism that splits up "cross listed" (or "linked") sections into their constituent classes.
We do not plan to transition all institutions at once. Rather, we plan to do them a handful at a time before they transfer to fall semester roster data. This will result in the minimum possible impact on developers, teachers, and students.
What exactly is going to happen?
On July 1st (or earlier, with your permission), we are going to flip a switch on any remaining districts that have not yet been migrated to this new data model. Please note, none of our endpoints or models themselves will change. Only the way that we sync data into our system.
- Nothing will change about districts, schools, or people objects. These objects will have the same IDs as before.
- The objects currently designated as "classes" in Edlink will become "courses" after the change. They will receive new IDs.
- The objects currently designated as "sections" will now become "classes" in Edlink. They will receive new IDs. The course_id will point to the newly created courses mentioned in the previous bullet.
- Enrollments will no longer have a section_id, although we will leave the property available (but always null) for backwards compatibility purposes.
- The "sections" endpoint will be available for backwards compatibility, but it will always return an empty array.
What districts or universities does this affect?
This change will only affect any institutions that use Canvas or Schoology that connected prior to January 2024. New Canvas and Schoology connections are already relying on this code.
Is this a breaking change?
Not exactly. There's nothing that's going to change about our API or data model. The difference is that endpoints that used to return Canvas or Schoology sections will now return an empty array (still a valid response).
The reason we're treating it like a breaking change is that Canvas and Schoology classes will receive new Edlink IDs, and this may cause a disruption for users.
What do I have to do to migrate my code?
Probably nothing. The vast majority of Edlink clients do not use sections for any important purpose. If you are concerned about migrating to new class IDs, please reach out to your Edlink Client Success Manager and we can discuss migration strategies.
If you believe you have classes that need to persist from the last school year to the next, please reach out to your CSM to discuss options.