As I was considering what subject I should dive into for this blog post, my mind kept going back to Banner setup for a new aid year. I kept saying to myself, “It is so early to be thinking about new year setup given the time of year.” I then started reflecting on why I was thinking about this at such an odd time. I can’t help but think it’s because of all the conversations in Financial Aid offices nationwide regarding the many upcoming changes.
FAFSA Simplification, Department of Education reporting changes, and system updates seem to be predominantly on the forefront of everyone’s mind, and understandably so. The most concerning part of all of this to me is, we don’t necessarily know what all these things are going to look like. When change and uncertainty is imminent, it’s very easy to forget about the things we already know or put them on the backburner. Unfortunately, this strategy can leave us scrambling to resolve issues if we aren’t careful. These issues that could arise are issues that we may not have time for given all the other work that is approaching in the coming months.
This is a two-part post to detail some things that I have seen over the years that are important to keep in mind when preparing for and setting up a new aid year.
Part One will cover New Year Roll and Population Selections/SQL Rules, and Part 2 will cover Batch Posting/Jobs and Process Automation.
New Year Roll
When it comes to rolling to a new aid year, the strategy for how to approach it can widely vary. Some prefer to do so manually, some use home-grown scripts, and some use the baseline-delivered jobs to accomplish these tasks. Regardless of which strategy your institution uses, I can’t stress enough the importance of checking your work.
For those of you who utilize a custom script or baseline jobs, this is especially important. In many cases, it is very easy to run a job to complete a new year roll and think everything is good to go. While scripts and jobs are very useful for accomplishing the new year roll process, I still highly recommend checking everything that was rolled to ensure accuracy. It is much easier to change a setting or a date than it is to clean up records after multiple records have been created using the options that were not checked.
Let’s not forget there is more than simply completing the roll process to setting up an aid year. The steps below can serve as a great guide for all related new year setup items. Also, remember that changes in a prior aid year can happen after a new year is rolled out! If this happens, the change that was made will not be included in the newly rolled aid year, and those changes will have to be made manually!
There are several ways that setup data can be checked. Utilizing any (or all!) of the below options are a great start to minimizing the risk of error when setting up a new aid year.
- A Second Set of Eyes!
I put this one first because I feel it’s the best and most accessible way to audit your setup. We’ve all had those moments where we get in a groove of running jobs, changing dates, and inputting data that our eyes glaze over, or we get so entrenched in what we are working on, we make a mistake or overlook something. I’ve found that utilizing a colleague to double check your work after the fact can save everyone a lot of time in the long run if mistakes are made.
- Utilize Your Database!
Navigating screens in Banner or Colleague is time-consuming. While it is important for you and a colleague to go through each screen to ensure accuracy, it may also be helpful to be able to get an at-a-glance view to dot all the I’s can cross all the T’s. Writing a query to compare the setup of the prior year to the setup of the year you just rolled is very useful for many reasons. Of course, this method does not ensure complete accuracy, but can serve as a good way to quickly see if there are inconsistencies.
To accomplish this step, I recommend writing a SQL script that looks at all the tables you updated during new year setup. Include one row for each aid year in your query and use this information to see if there are discrepancies. Some discrepancies are expected (dates, any changes to processes), but this is a great way to get a general overview of what has changed, and if it indeed should have changed.
Utilizing this step is also useful for documentation and for answering any questions from functional users as to how the new aid year was set up. Being able to look quickly at where data is located can prove to be valuable in the event there is a change, and you have to make updates quickly.
- Provided Tools
Ellucian provides a new year checklist as well as a series of SQL scripts that can be run to check the setup items that have been completed for a new year. Utilizing these tools can be a very useful tool in making sure that you have set up your system appropriately for the upcoming year. These tools also cover more than just the New Year Roll, specifically, so it gives a very nice comprehensive resource of what all will need to be done for setup once the new roll to the new year is complete.
Ideally, I would recommend using some combination of all three of these recommendations when completing new year setup. With confidence in your initial setup, you can confidently move on to your next steps.
Population Selections and SQL Rules
Once your new year roll is complete and you feel good about your system options, it’s time to move on to the more technical aspect of new year setup. If I’m being honest, this aspect of new year setup is what I blame many of my gray hairs on 😊. While it can be stressful, these items are what in my opinion separate a good system from a great one, so it’s important to get these things right!
All schools are different in how they utilize population selections, rules, batch posting, and baseline or custom jobs. While the approach may be different, what is important is that everything be checked to make sure the right records are being selected and the right processes are being run on them. Below are some things that I have seen over the years that are important to check, but often overlooked.
- Hard-Coded Terms, Aid Years, and Other Values
I normally like to start here when I’m setting up a new aid year. While many SQL statements are dynamic by term or aid year, not all of them are. Also, aid year and term-related references can be in sneaky places that are often easy to forget about. Some institutions use aid years to identify their application codes for population selections, some use terms/aid year codes in their titles and descriptions, some have rules with hard-coded items in some places and not others. Completing a thorough check to make sure all of this has been done is very important and can save a lot of frustration down the road, making the upfront time you put into these reviews and updates very worth it.
It’s also worth keeping in mind that more than just terms and aid years can be hard coded into SQL rules. It’s always a good idea to take a look at hard-coded values along the way to make sure anything does not need to be added or removed (think about tracking codes, fund codes, packaging groups, etc.).
- Location, Location, Location!
Keep in mind, SQL rules live in a variety of places in the Financial Aid module. Depending on what you are set up to utilize, you could have SQL scripts that need updating in almost 10 different banner forms – and that’s not to mention how many rules may be used in each of these! Also, when updating SQL in some Banner forms (RBRABRC for example), don’t forget about the Validate button! It’s also a good idea to make sure any changes made utilizing GLRSLCT are compiled. This just means running GLBDATA on any population selections that you’ve made changes to.
Here are a few Banner forms that may house SQL that needs updating: RORRULE, GLRSLCT, GLRVRBL, RPRALGR, RORALGO, RORWBQA, RORWTXT, RORWVAR, RBRABRC
- Table Changes
While we don’t have specifics, we know that there are major changes coming in the 2024-2025 aid year. In order to accommodate these changes, there will likely be new tables to consider, and some that may no longer be needed as well. Accounting for new tables can be tricky, especially when two different aid years may be current and there is a need to use both sets of data. If this happens, you will be well-served to have a plan in place for how to identify these tables, and where rules exist that require changes to be made.
Conclusion
There is a lot covered in these posts. There is always so much to keep in mind, and with the upcoming changes, being on top of our Financial Aid systems is a very high priority. When it comes to any of the items covered, our consultants at Strata Information Group are happy to assist your institution’s needs. If you have any questions or would like to follow up with us regarding any of these topics, please feel free to contact us. We would be happy to assist you with your next steps!
Written by Daniel McClanahan, Senior Consultant
Daniel specializes in Ellucian Banner functional and technical processes related to Financial Aid, Admissions, Accounts Receivable, and Registration where they interact for end-user support. He provides functional assistance to solve errors, problems or questions with programs, and trains functional and technical staff to use programs across departments. Functional expertise includes algorithmic packaging, direct loans, disbursement, financial aid common functions, needs analysis, period-based algorithmic budgeting, post-implementation assessment, SAP, transfer monitoring, and self-service. Technical expertise includes SQL, PL/SQL, Argos, other SQL based reporting tools, and AppWorx.
