Blogs

 Summer has given way to fall here in Minnesota - leaves are changing, asters are in bloom, and soups and stews are on the mind. For those soup-connoisseurs out there, I’m guessing you have had your fair share of experience straining fats and oils in a broth. It isn’t that we necessarily don’t want the fats and oils in our cooking, we just don’t want it in THIS broth. So you let the oils float to the top of the broth and use one method or another to remove the fat and focus the rest of your attention on the broth left behind.

 Aside from the fact that I’m hungry while I write this, I can’t help but see this imagery when I think about unit/course local limits in Academic Advisement. You identify a subset of courses (the oil and fat in our broth floating at the top) and determine how many, if any, of those courses are allowed to be allocated to degree requirements (the oil straining piece of the metaphor).

 Effectively setting up a limit can be a challenging and confusing task, especially if you are configuring a limit to enforce something unfamiliar because you have a new type of degree requirement or a new need arises in your world. At the University of Minnesota, we were faced with enforcing collegiate policy that did not allow courses taken prior to admission to count toward a degree. I am going to share with you how we have been able to successfully enforce this collegiate requirement. Shout outs go to my colleague, Clare Dingley, who took the lead on investigating and testing this solution, and to the AA HEUG community for their brainpower and assistance on this!

 Quick side notes:

• Since our need at the University of Minnesota was related to a collegiate requirement and policy, our solution was to use Local Limits (in PeopleBooks language) and not Global Limits.
• Regarding my terminology: throughout this post I am going to refer to our solution for limiting courses taken prior to a student’s requirement term as a “pre-admit limit”.

 Here is an outline for how we have this limit configured. At a high level, the solution we identified uses a combination of a wildcard Course List that identifies the courses we care about for this limit, and a Requirement line item local limit that enforces a 0-unit limit. Therefore, I’m going to talk about this in three stages:

1. Setting up the wildcard Course List
2. Setting up the Requirement
3. Adding the Requirement to the Requirement Group

 Setting up the wildcard Course List

The Course List is where a lot of the magic is happening. The Course List is configured to capture the courses taken prior to a student’s academic plan requirement term.

1. Course List Description: the Course List has an effective dated row using the first day of term. The earliest effective date we use is the first term that degree programs began using Academic Advisement at our institution. We then have a new row dated for each fall and spring term (note: summer effective dated terms were not needed because the impacted degree programs do not admit in the summer). We have pre-configured effective dated rows as far out into the future as the University’s approved academic calendar (four years out) and we add rows annually in August to capture newly approved calendar years.
2. Course List Detail: the only course on this Course List is a wildcard course with all blank values to capture all courses.
3. Course List Parameters: this is where we home in on the courses we are going to limit. In the “Valid End” field on each effective dated row, we enter the day before the first day of the term of that effective dated row, (in other words, effective date minus 1 day). For those unfamiliar with these fields, the valid begin and valid end dates are used to constrain courses based on when the course is taken (more specifically, when the course is started) by referencing the course’s scheduled start date. In our setup, we are using the “Valid End” field to pinpoint any courses started before the first date of the student’s requirement term, like a chef determining how much oil to strain off the top of the broth. Being familiar with how your institution sets up terms and sessions is very important here.
1. For example, during testing we found some courses associated with a student’s first term were not meeting degree requirements, i.e., they were being limited. Further investigation revealed that these courses were scheduled to begin on a date that started before the term begin date. The University of Minnesota calls this the "Extended Term Session". The term the course was taken was the student’s first admit term; however, the first day of class was scheduled to begin prior to the first day of the term. Since the first day of the term is the date we use to determine the “Valid End” date on the Course List, the course was limited because it started before the “Valid End” date. Lesson learned: this setup strictly uses the course’s scheduled begin date for enforcing the limit. A course will be limited with this setup if the course’s begin date is before the “Valid End” date used on the Course List - even if the course is taken in a term that begins after the “Valid End” date.
2. As with most things in AA, it is very important to understand the relationship between a student’s requirement term and effective dates in order to understand this setup since the requirement term determines which valid end date on the Course List is being enforced for the student. If you haven’t read it yet, I recommend taking a look at Brian Rockwood’s post about effective dating and the “Price is Right Rule”.

 Setting up the Requirement

Since the exclusion of pre-admit courses is tied to a specific degree program at our institution, each of which is represented by a single Requirement Group in most cases, there is a unique Requirement created for each Requirement Group where the limit needs to be enforced (but we can use the same wildcard Course List in all of those Requirements). The sole purpose of this Requirement is to use the wildcard Course List to enforce this 0-unit limit and prevent pre-requirement term courses from allocating to a degree’s requirements. To return to my metaphor, now that we identified how much oil to strain, the chef is straining the oil and fat off the broth.

1. This Requirement does not print on the audit, so we use the various description fields to capture information about the collegiate policy and document what is being limited.
2. Requirement Parameters: values are blank and Print Control is “Do Not Print”
3. Line Item: Line Type is “Unit, Course or GPA Limit”
4. Line Item Parameters: Maximum Units Allowed = 0
1. Note: We also enter a Maximum GPA Allowed = 4.00 and Maximum Courses Allowed = 999.00. Your institution may approach configuring a 0-unit maximum limit in a different way. I learned of these different approaches while investigating some recent Oracle PUM-related bugs.
5. Line Item Detail: two rows are intersecting
1. The first row is a DLST Used By Requirement Group. The Requirement Group is the Requirement Group for the degree where the limit is being applied. This DLST is why we need to create multiple Requirements for limiting courses taken prior to a student’s requirement term.
2. The second row is intersecting (I) the wildcard Course List (CLST) detailed above in part 1.

Adding the Requirement to the Requirement Group

After setting up the Requirement, we now need to do the final step and add the Requirement to the appropriate Requirement Group. There are only a few graduate and professional degree programs at the University of Minnesota where this local limit is needed, so creating and maintaining a unique Requirement for each degree program’s Requirement Group was not burdensome. As stated earlier in part 1, the regular maintenance this setup requires is adding rows to the wildcard Course List annually in August to capture newly approved calendar years.

 On the Requirement Group Detail tab, we add the “pre-admit” Requirement after all the other degree-related Requirements. We found that adding local limit Requirements last in the AA processing logic resulted in a more reliable enforcement of the limit.

 In our setup, the “rejected” courses (i.e., those taken before the student’s requirement term) display in our generic “Courses Not Used” Requirement Group at the bottom of the audit. The limited courses are still visible and can be easily directed to a requirement using an exception. A quick look at when the course was taken versus the student’s requirement term easily identifies the limited courses. At long last, we have strained off the fats and oils from our broth and set the excess aside for a different use should the need arise.

----------------

 That wraps it up! If you’ve made it this far, I thank you for taking the time to read this! Finding a way to configure a unit local limit to enforce this collegiate requirement was a major win for us at the University of Minnesota, so I am glad I had the opportunity to share this with you. If you have a similar requirement at your institution, I hope this information will come in handy. Please feel free to reach out to me if you have questions.

 Happy fall, everyone! Now go make yourself a hearty soup and ponder the wonders of local limits!

 Chris Abts