I cannot believe that it has been five years since we officially went live with Workday Student. I am often asked if Workday Student has all the functionality one needs. Sometimes a few who have not yet implemented Workday will make a statement like “Workday Student doesn’t have all the functionality we need”.

Let us face it, no SIS has everything one needs, period. And to expect them to do everything everyone of us wants is unrealistic expectation. This is precisely why, we surrounded systems like Banner and PeopleSoft with several other products. And customized these products in ways that came to bite us when major upgrades were rolled out.

For us, even with Workday, we continue to have some of the additional systems, but less than before and we have successfully adopted a lot of the native functionality of Workday. Using its excellent integration methodology we have increasingly centralized a lot of information that were non existent or were all over the place. And by using its low-code programming platform, Workday Extend, we are moving more and more of the functionality that were externally programmed. Doing so presents the users with a unified interface like the native Workday. In addition, the product is supported and has followed the rest of Workday when it comes to upgrades – the applications work for the most part and if changes are likely to affect them, you have sufficient notice to fix them. Finally, we have built the student datawarehouse using Workday Prism. Such centralization, I don’t have to justify, has clear advantages and lessens the total cost of ownership.

I would like to share our experiences with the hope that it helps clarify what are the capabilities of Workday Student that have worked out well for us. Because of the length, I am splitting it up in multiple posts.

Registration

I can say without a doubt that the registration experience after we have moved to Workday has been one of the best. Early on, at Wesleyan, PeopleSoft’s registration was not mature enough for us to use it, so we continued to use our homegrown registration system (which I co-wrote) until a few years ago. Both Banner’s registration system and our homegrown system at Wesleyan suffered from the technology stack used – web servers talking to backend databases. The amount of work that needed to get done when hundreds of students clicked (time conflict check, prerequisite check, any reserved seats etc) at the same time did not scale well in this architecture. Every registration had several disappointed and upset students and parents because of the browser spinning because servers were busy! Throwing more hardware at this was not only wasteful (because they will be idle most other times), but  it cannot help beyond a point because of the technical limitations of multilayered architecture. Also, getting any real time data to help diagnose issues was nearly impossible.

With Workday, we never hear of browser issues. The elastic architecture and the ability for us to create a ticket before registration to adjust the resources in cloud has worked well us. And the amount of real time data available regarding registration, such as Registration Audit History, has been fantastic for our Registrar’s office to try to understand why a student was not able to get into a class. It records the event at microsecond level. I complain to Workday that we need this at nanosecond level!

Workday allows students to plan well ahead what courses they want to register through what is called Saved Schedules. It is like a registration plan. When students prepare these, it scans for various eligibility rules including prerequisites and any permissions needed etc. and flags them for students so that they can go ahead and refine it for maximum success. This, combined with registration audits and waitlists (see below) can become an excellent way for department and program chairs and the Provost’s office to analyze course demands and do capacity planning. We can also analyze which saved schedule a student tried to register from and what was the success rate. For example, we can discern how many had 4 sections in their saved schedule and how many they successfully registered in.

For a variety of reasons, we were unsuccessful in implementing prerequisite checks and waitlists the way we wanted at Wellesley in Banner. I built a waitlist system for this reason completely outside that co-existed with Banner and over a period of time, like all such systems, it was bloated. Our faculty were happy with its capabilities, but in the back end it was becoming hard to maintain. With Workday, more than half of our classes use the native Workday waitlists. Most are first come first serve, but for several, the faculty control the waitlist based on different criteria such as moving the seniors to the front of the waitlist etc. We continued to use home grown version for a small number of classes where we needed waitlist for Lecture-Lab classes. it is nontrivial to manage waitlist for these (I am happy to explain why to anyone interested!!!). But, I am SO HAPPY that we have shelved our homegrown process for this and have found a way to manage these within Workday waitists starting from the Fall 2024 registration that just completed.

Bottom Line – Registration works great from the student perspective (I know that some students are not happy about not getting the classes they want, but that is not because of technology). We have an external process to collect information from the instructors about the courses they want to offer and through integrations we create these sections with appropriate configurations. We now offer more ways to control the aspects of their sections than before such as prerequisites, permission of instructor etc. We intend to move this process to Workday soon, using Workday Extend.

We continue to work with some of the departments which have significant challenges with demand, such as Computer Science and some of the Science classes with Labs, to come up with various ways to help manage these issues in a fair and equitable fashion. Workday configurations allow us to accomplish some of these issues.

One issue that comes up is how in Banner you can exceed the enrollment cap without changing the cap. This you cannot do in Workday. Instructors used this to make sure that they can selectively enroll students in addition to the cap, but when someone dropped the course, that seat now doesn’t become available unless the total falls below the cap. This is not possible in Workday and we have basically addressed this through eligibility rules, but some faculty miss that feature of Banner.

In my next post, I will discuss how we are managing some aspects of Advising.