-implemented WF
-decrease processing time
-eliminated multiple ad-hoc reports
-packaging process before WF
-after WF
-including steps and examples
Old process: we ran a process to pick up students who were ready to be packaged
identified SAR C, Federal Rejects, verification information discrepancies, correspondence (ie special circumstances) that was received and kicked them out on a report
All others were packaged through RPEPCKG.
Those on the report were manually reviewed, follow up if necessary by emailing students and coding RHACOMM, and packaged by the staff.
Process ran once a week. Because the process was weekly the number of student accounts that needed to be reviewed was large.
We use custom views to identify groupings of students and are used in group assignment jobs for processing.
For example, a student will be identified as new or continuing. As well as being and undergrad, graduate, or if they are students from our Law or Manchester campuses.
We use custom parameter sets on the GJAPCTL form to store values which different processing is based. Have custom parameter sets to allow flexibility of who is going through the process
We use applications Manager to schedule and run jobs in batch at night as well as ad hoc through out the day.
We took our same process of when students are ready to be packaged.
A workflow is initiated for a student when they have become complete. This means that all requirements the Financial Aid office deems required to be packaged has been provided.
The workflow evaluates the banner data for the student and determines if the student has any exceptions such as a SAR C.
The exceptions that were on the rosters are now in staff Worklists.
The staff reviews the exceptions in workflow and once the data is correct and the student no longer has any exceptions the student id will be inserted into a population selection to await packaging. We run RPEPCKG nightly in batch.
The financial aid office wanted the ability to control whether the workflow was on or off by aid year and by student groups. Using custom parameters helped to give the flexibility the Financial aid office wanted.
Why do we want the ability to turn off by aid year – ending out a new year, not ready to begin packaging for an upcoming aid year. Might be ready to package undergraduates but not graduates.
We created a custom process to create workflows for students in batch. This is used at the onset of the upcoming aid year to capture anyone who may have become complete before the workflow was turned on. This process is run via applications manager at night in batch. We have experienced workflow performance issues while initiating to many workflows at once.
When the rorstat_pckg_req_comp_date is date populated a workflow is initiated for a student.
The first workflow component returns student data needed to complete workflow steps.
The workflow is assigned to a staff member based on student last name. A group of 5 staff split up the student review process based on alpha. This alphabetical breakdown can change yearly and therefore the staff and the alpha breakdown is controlled via a custom parameter set.
The next component returns any exceptions a student may have.
If no exceptions then student is ready to be packaged and is inserted into population selection. So out of 6700 workflow that were created there were 120 exceptions.
This is the process flow from beginning to inserting into a population selection.
Inserted into population (GLBEXTR) to be used by RPEPCKG
Based on Student ‘Group’
- New vs Continuing
If more information is needed
Workflow sends email to student
Workflow updates/inserts tracking requirements using baseline APIs
Workflow inserts comment to RHACOMM Checks exceptions (continued):
If exceptions can be corrected, the process rechecks student eligibility and if clean (no more “exceptions”) then student is inserted into population selection (GLBEXTR)
Next example is when packaging exceptions exist.
Shows in a staff person’s Worklist.
This staff will view all exceptions for a student at once. This consists of SAR C’s, federal rejects, correspondence, deselects (such as household size, number in college, food stamps), aid awarded.
We use ssd axiom to scan and index our verification documents. So if the household size coming in on the verification worksheet does not match the data on rnana it inserts a requirement on rraareq and comments on ROUASDF. These comments are displayed as the Deselect Reasons above.
Talk about ‘DESLCT N’ process – when discrepant info DESELCT N input on RRAAREQ and reason in ROAUSDF
The staff has the opportunity here to stop or continue the workflow as they see fit.
Here you can see that the process flow has followed the path through to the view_student exceptions component.
At this point the staff has reviewed any issues with the student record.
If the errors were corrected then the staff can select ‘the continue’ workflow button. This brings the workflow back to the check_student_exceptions component.
If the student still has no exceptions then the workflow process will follow the Student Ready for Packaging Guard condition and it will insert into the population selection.
If more information is needed from the student, then the staff select can select to have workflow send an email to the student requesting clarification.
We will follow and example and details next.
The workflow will then update and insert tracking requirements on RRRAREQ that data has been requested and a message on RHACOMM using BANNER API’S.
Reviewing Discrepant Household Size in Workflow
-coded on RRAAREQ as incomplete
If we have someone whose household size or number in college doesn’t match then the staff will compare values in RNANAxx to values on verification worksheet in Xtender and determine if they can resolve or if they need more information.
If it can be resolved then the staff will hit stop worklfow. If not then they will select continue.
Depending on the student status either the exception is resolved and it will insert into population selection or email follow up is needed and update to banner will occur.
If follow-up is needed:
an email will be sent to the student requesting needed data
Banner is coded (RRAAREQ) to prevent further processing – Discrep E
Message will be posted to RHACOMM indicating status
Then select yes or no to sending automatically sending email to the student or sending the student back up to the beginning of the workflow to recheck for exceptions if they have determined the correct data has been received.
Scholarship candidates are manually coded on ROAUSDF and identified accordingly (Admissions info).
-picked up as an exception in Workflow
Staff manually awards aid in Banner. -once staff awards aid and marks workflow complete, workflow evaluates whether student is new or continuing (based on our custom views)
- If new/incoming student and is awarded the scholarship, email sent to student with scholarship details
Staff views the special program form in their worklist.
Moves into Banner to award aid.
If student is eligible for the scholarship and it is awarded an email is triggered from the workflow to the student.
We often have the need to delay the initial packaging of different Student Groups.
Each campus operates with different packaging guidelines. This functionality allows us to be able to create workflows for students and continue with the review of the student requirements and exceptions while preventing them from being packaged.
We are using a combination of custom parameter sets, custom views, and the Activity Timer Diagram to delay students from being inserted into the population selection.
The Check_Student_Group component checks if the student group (ie Undergrad, Grad, Law, Manch) is currently entered in the custom parameter set.
If not, the guard condition sends the workflow to the activity timer component to recheck in 5 days if there has been a change.
The Financial Aid Office would like to eliminate the need for the population selection.
The ideal situation would be for RPEPCKG to be initiated from within Workflow for a student when the student meets all requirements.
From the FA perspective –better able to serve students by decreasing time of processing.
More students went through our initial run of packaging for our new students since we are able to work on the “exceptions” earlier (instead of waiting for batch packaging to run and getting rosters of these students).
We expect to see a much larger number of continuing students go through our initial run in May.
Staff was able to review student records faster due to less time spend manually updating banner and composing emails.
Because student review is happening faster we can move from a weekly to a daily process.
