campuslogicinc

Introduction

Unexpected changes are any updates to data fields that differ from the “verified” ISIR values. Historically if an unexpected change has been found, the latest transaction is re-opened to a Reviewing File status to have school users choose to request additional information from the student, submit a new correction file with the updated value(s), or choose to ignore it. The only exceptions are when new student actionable comment codes are introduced or a change in data requires the Verification worksheet to be re-opened, then the Verification transaction will always open to Re-Collecting status to create a new task or re-open the Verification worksheet. 

Your institution has the ability to divert subsequent ISIRs with unexpected changes into a separate workflow when a student’s Verification and/or PJ EFC transactions are in a Verified status. This process stops additional file review records for subsequent ISIR changes from being mixed into the normal file review workflow that typically requires documentation review and validating any corrections that need to be created.

Enabling the Subsequent ISIR File Review Queue

In order for the Subsequent ISIR File Review Queue to open, you must enabled it in the Settings as an Admin.

• From the Admin menu, open School Settings
• Select the Basic settings tile
• Within the Transactions section, turn on the switch "Enable Subsequent ISIR Queue"
  • Please note: the Subsequent ISIR Queue only works for 2019-2020 and future award years

• click Save at the top of the page

WARNING: Please note that once you enable this functionality, you must be careful if you decide to disable this process at a future date. For any subsequent ISIR records in queue, it's corresponding Verification/PJ EFC transaction is held in a new transaction status called Subsequent File Review and will be stuck in that transaction status if not resolved in the subsequent ISIR queue. If you wish to disable the functionality, you need to clear the subsequent ISIR queue first to ensure Verification/PJ EFC transactions do not get stuck in this status.

Subsequent ISIR File Review Queue

Once the Subsequent ISIR File Review has been enabled, you will see the new workflow tile located the Workflow page. If you do not see this right away, you should refresh your page (press Ctrl + F5 together), or logout and log back into the application.

The functionality of the Subsequent ISIR File Review is very similar to the File Review and Appeal Review workflows. The workflow will show you the total number of outstanding Files Available for review, the current number of Files Pended, an option to View All records in the queue, and an option to Get Next File, which also runs on a first in, first out (FIFO) basis, meaning you'll go to the oldest outstanding file not currently pending.

When viewing all records, the screen and grid also mimic the File Review and Appeal Review screens. You may filter by award year or dive deeper with Advanced Filtering, which gives you the option to filter by Verification groups and/or Comment Codes, student identification (first name, last name, student ID), by status and review dates, whether the record is currently pending or not, and a filter to review by transaction type (Verification/PJ EFC).

Subsequent ISIR Comparison

Whether clicking the Get Next File button or selecting a specific record from the grid, you'll navigate to the Subsequent ISIR Comparison page.

The Subsequent ISIR Comparison tool is similar to the ISIR comparison page where you can determine the change in values from the ISIR that verified the transaction to the subsequent ISIR containing unexpected changes. A couple of notes about the "Verified" ISIR and the subsequent ISIR used:

A Verified ISIR is either:

1. the ISIR that was used during Verification file review where the outcome was no corrections were needed - the completion of file review instantly updated the Verification transaction status to Verified
2. the subsequent ISIR that came in with expected corrections processed during file review and pushed the Verification/PJ EFC transaction to Verified status

The Subsequent ISIR used is the most recent subsequent ISIR loaded into the application that contained unexpected changes from the Verified ISIR. 

• For example, ISIR 2 was the ISIR that pushed the Verification transaction to a Verified status. ISIR 3 comes in with unexpected changes, causing the Subsequent ISIR Comparison to take occur. But before a school user has a chance to review the subsequent ISIR record, ISIR 4 comes in also containing unexpected changes. ISIR 4 is now the most recent ISIR with unexpected changes and will be used to compare to ISIR 2, which is the Verified ISIR.

This screen will compare the Verified ISIR, the Subequent ISIR, and the Document Values found from any documentation collected from the transaction. By default the fields will be filtered down to only the fields displaying any Discrepancies. If you wish to view all ISIR fields, you may disabled the switch "Only Display Discrepancies" - this will still show the exclamation point indicator of any field with a discrepancy.

At the bottom of the screen, there are two options to resolve this issue. You can either:

1. Ignore will revert the transaction status back to Verified, meaning you do not want to take any action against the discrepancies found
2. Reopen will push the transaction status to Reviewing File, where you can request additional documentation from the student to clear any issues found, or simply complete the file review to process new corrections.

This screen is used to help determine whether you would like to take action on the transaction or not - this does not take actions like sending new corrections or give you the ability to request additional documentation.

There are instances where the subsequent ISIR record will be removed by the system automatically:

• If a subsequent ISIR record is still outstanding and another subsequent ISIR comes in with the expected changes of the Verified ISIR, the application will revert the transaction back to Verified status
  • For example, ISIR 2 was the ISIR that pushed the Verification transaction to a Verified status. ISIR 3 comes in with unexpected changes, causing the Subsequent ISIR Comparison to take occur. But before a school user has a chance to review the subsequent ISIR record, ISIR 4 comes in containing the expected changes and matches the values from ISIR 2. The subsequent ISIR comparison is no longer needed and the transaction is moved back to Verified.
• If a subsequent ISIR record is still outstanding and another subsequent ISIR comes in with a new student actionable comment code, or there is a change in Verification information requiring the student to re-complete the Verification Worksheet, the application will automatically open the Verification transaction to add the new tasks/reopen the Verification worksheet.

Workflow

The subsequent ISIR is always compared to the last actionable transaction between the Verification and PJ EFC transactions, meaning the last transaction where file review was completed and either that transaction is currently in Processing Corrections status and awaiting a subsequent ISIR, or has already been completed and pushed to a Verified status.

A good example of last actionable transaction being changed multiple times is the following scenario:

• A student is selected for Verification and completes the Verification Worksheet and provides tax documentation within the Verification transaction. Once a school reviewer completes file review, the Verification transaction becomes the last actionable transaction. Later on the student requests a PJ EFC, provides the required documentation, and the school reviewer approves the PJ request. The PJ EFC transaction has now become the last actionable transaction. Finally, a subsequent ISIR comes in with a new comment code for defaulted loans and the Verification transaction has reopened with a new task for the student to complete. Once the student submits the documents and the school reviewer completes file review, the Verification transaction once again becomes the last actionable transaction.

The only scenario where PJ EFC does not become the last actionable transaction is if it is Declined or Rescinded (revoked), because there are not changes to be made or expected from a subsequent ISIR.

There a four main scenarios to consider: 1) Verification is the only transaction opened, PJ EFC never requested; 2) PJ EFC opened and the Verification transaction is already completed; 3) Verification reopened after the PJ EFC was completed; and 4) PJ EFC is the only transaction opened, Verification never opened due to not having student actionable comment codes.

Below is a breakdown of those main scenarios, where based on the previous transaction (if any) and what the current transaction status is, the subsequent ISIR with unexpected changes will choose a transaction to run it's comparison against.

When enabling the new subsequent ISIR queue, rather than re-opening the transaction in the Verification or PJ EFC file review workflow, a temporary record is added to the Subsequent ISIR File Review workflow. This workflow allows you to quickly review the unexpected changes of the new ISIR compared to the last actionable, completed transaction. From there you may choose to Reopen the transaction back to Reviewing File (like the process normally does when the subsequent ISIR queue is disabled) in order to collect more documentation or send new corrections, or you may Ignore the unexpected changes to push the transaction back to Verified status.