Moving schedules from ofCourse to the parent SIS

We have a challenge in what we do. Our goal is to empower schedule makers, make them feel bionic, make them look like the coolest, most capable schedule makers in all the land. We have lots of evidence we are over-delivering on this front. But the challenge I mention is somewhat out of our hands and comes at the tail-end of the workflow. There comes a point where you reach the end of your ofCourse experience and need to extract your beauteous, vetted schedule from the ofCourse system and get it loaded into your school's system of record. Or put differently, there comes a time when you must leave the cozy and bright confines of the ofCourse interface and return to the dank and joyless world of your parent system. If I had more of a theatrical bent and better vocal skills, I would start humming the imperial march from Star Wars.

Unfortunately, this part of our tale is not likely to have a storybook ending. Universities are notoriously siloed landscapes, and the reasons for this are both fully understandable and defensible. There are loads of sensitive data in the hallways of a university information system. Were I in charge of any of it, I surely wouldn't just let anyone roam the halls. Heck, these data owners often don't allow other people at their own institutions in the building, hence the silo-effect, so they are surely not going to be keen about admitting some third-party stranger to the party. I get it. But it still soils the end of our workflow.

Thus far, when it comes to transferring a finished schedule from the ofCourse system to a school's parent system (e.g., Banner, Naviance, etc.), schools do one of two things. The first option is to re-enter the schedule manually into the parent. Some registrars voluntarily elect to go this route because they like that final touch-point with the schedule before sharing it with the world. Some registrars do this because their school might lack the requisite tech-support to assist them in facilitating a systematic transfer.

The second option for schools is to pursue a more automated upload of the data. For the reasons noted above, performing a FULLY automated import from the ofCourse system into your school's parent system will likely never take place. That said, some things can be done to assist in porting the data produced in the ofCourse system to your school's parent in a manner that should reduce the time, potential for error and expense of a manual transfer.

We approach this by storing one additional bit of information in the ofCourse system--the database identifiers used by your parent system to identify your school's assets. In this scenario, we are talking about your professors, your courses, and your rooms. While Professor Andrew Martin is known and shown as Andrew Martin to the world, Professor Martin also has a numeric id that the computing system uses to track him (e.g., 2006212). For schools that wish to do automated imports, we collect and establish these database identifiers during your setup.

Telling the difference between a school using Database Identifiers in the ofCourse system and not using them is near impossible, until the very, very end of the process. The first time you might note the difference is when you arrive at the last step and do a text export of your schedule. For schools that are employing the Database IDs, there will be three extra columns in their text export--Faculty Database Id, Course Database Id, and Room Database Id. In these columns, you will see numbers that will align with your parent system, and that is how that parent system will know what person, class, or room is being referenced in that row of data.

When you have a finished schedule, this text export file can be sent to your I.T. group who will use the database identifier columns to craft reliable insert statements and/or scripts to port the schedule data into the parent system. There will likely be some subsequent massaging and review necessary after the import (e.g., course section assignments, secondary professors), but the bulk of the labor can be mitigated with this initial transfer.

As you would guess, your landscape will change from year to year. Every term will likely see new faculty being hired and new courses approved by the curriculum committee, and maybe even a new room or two brought into scope (we can dream after all). Using the ofCourse Administrator interface you will have the ability to add new people, courses, and rooms to the system but, this begs the question of what about their database IDs. There is a field on the add and edit form for the Database Identifier. This means you can continue to populate that data on your own and will not require the ongoing assistance of ofCourse technicians to keep your data current.

Another matter to note regarding new people and courses is tracking where you might have a missing database id or two. To assist in ensuring that your text exports include all the necessary database IDs, even for newly added people and courses, you will see an additional report just before you export the data. This report exposes any missing database identifiers from your environment and prevents you from having to do a seek and find on your own to discover any holes that require filling.

When missing items are reported in the Status Report, you can use another tool we have, the Manage Database IDs Utility to (1) see the exact ids that are missing and (2) enter those missing ids into the ofCourse system. Naturally, you will need a way to find those missing identifiers in your parent system. This typically plays out in one of two ways.

1. The schedule maker can access the parent system and find/see the item's database id. Sometimes this is easy and obvious. And, sometimes someone from the I.T. group can show them how to spot the Database Id.
2. The schedule maker sends a list of new elements to the I.T. group, and someone from the I.T. group looks them up and sends the id numbers back to the schedule maker who can then enter them into the ofCourse system.

However, you go about getting the database IDs. Once you have them in hand, you can enter them into the ofCourse system using the Manage Database IDs Utility. And, once all of the missing ids have been accounted for, you can do your text import and send it to your I.T. group for processing.

Lastly, subsequent changes to the schedule that will continue to happen through the year will be handled individually. The process noted here applies to the INITIAL export of a newly constructed schedule in ofCourse and its import into the parent. This scripted import will not have to happen for the occasional and ongoing sorts of updates that are common every year as they are entered and handled individually. But that is a story for another day.

As always, see you on the scheduling pitch.

Troy