6.0 Product Brief

Regent Fund’s unified smart form is configured to streamline the application process across all your scholarship programs, supporting additional applications as desired. Proactive communications ensure students stay on track to complete the process.

Regent Fund integrates multiple, disparate data sets from student scholarship applications, ISIRs, your SIS, and other institutional data to give you a more complete picture of the entire applicant pool.

Regent Fund’s flexible and intelligent matching, ranking, prioritization, and selection capabilities enable you to award scholarships in an automated, configurable, and intelligent way.

Regent Fund’s queries and reports increase your visibility into the full scholarship management lifecycle, help you understand where you are with your awarding and enable you to share results and insights with donors and stakeholders.

Regent Fund’s automated budget tracking capabilities allow you to quickly reattribute unused, cancelled, or unaccepted dollars to new recipients. 

Questions in a scholarship application Smart Form can be configured for the student responses to be available to Regent Fund queries.  The following fields for any Document Requirement configured with a Smart Form type are available to queries: Question Code/Question Value (student response), Document Name, Document Scope, Document FAY, Document Expiration Date, Document Received Date.

Access to Regent Fund functionality is via the new ‘Tools’ left-hand menu option.  The Query Tool is the first step in the Regent Fund awarding process. Regent Fund operates at the Institution level, but queries can limit eligibility requirements to students from selected campus(s) or site(s) within that Institution. Only users with full Institutional access should be permissioned to work with the Regent Fund toolset or they may not see or be able to act on the full results of a query.

Regent Fund makes data from Smart Forms, ISIRs, SBLs, and from within Regent Award available to Regent Fund Queries. This data is cached for access by the query tool, and the cache should be refreshed regularly.  Administrators can elect to update the cache in real time via a setting on the new Query tab under Institution Setup, or the update can be initiated manually as needed. If configuration for terms, programs, or other data fields used in queries is changed, be sure to run a full batch packaging to persist changes to the student’s Academic Plan and other functional areas prior to updating the cache.

Clients use the Regent Query Tool to create, edit, copy, and save queries, accessing the functionality via the Tools menu.   ‘Regent Query Builder’ functionality provides an easy means within the user interface to build queries with drop-down menus and groupings.  Selected data fields are available from Smart Forms, ISIRs, SBLs, or Regent Award.  There is also an option for the more advanced ‘Regent Query Language’ (RQL) whereby advanced users can directly write a query using the Regent Query Language (RQL) fields and logic operators in a SQL-like format.   A query must be initiated with Regent , but then the user can switch to RQL to add additional logic, fields, etc.  Please note that once a query is saved in the RQL editor, the user cannot flip the edited RQL query back into Query Builder mode.

When a saved query is run, the process will return a list of students who meet the specified on the Preview tab on the query. There is an option to request an exportable file with more student details related to the query fields. 

A few tips:

Regent Fund provides a means to prioritize the pool of students who meet the eligibility criteria from a query.   Users specify the data elements to be used for sorting or ranking. There are options to use a cumulative points or weighted points ranking approach, and an option to award ‘renewals’ first (students who received the fund the previous scope period - academic year or FAY). Any ranking or prioritization of eligible students is really only necessary when there is a limited amount of   Regent Award’s current budget functionality will also help manage funds with limited amounts.

The Ranking and Priority Setup can be accessed from the ‘Tools’ Menu.  Permissioned users can add, copy, edit, and delete these setups. Each distinct Sorting and Ranking criteria must be configured separately by first selecting the Institution(s) that will use the setup, and then selecting the various options for sorting and/or ranking.  Current sorting and ranking options include an array of GPA choices (such as cumulative, SAP, or high school), EFC, FAFSA Completion Date, and UDF. Sorting can be set up for multiple factors, for example to sort first by FAFSA Completion Date and then by EFC to prioritize those students by EFC if they all have the same FAFSA Completion Date.  In addition, users can rank elements by assigning points to specific values. or ranges of values Ranking prioritization can be calculated by the ‘cumulative points’ of the scores amongst all ranking elements selected or by ‘weighted points’ for each ranking element selected. 

Students who received an award in the current year can be prioritized for awarding as ‘renewals’ in the next year by checking the ‘Renewal Priority’ checkbox.  Any sorting or ranking criteria will be applied first to renewals, and then to newly eligible students.

The Awarding process available from the ‘Tools’ menu provides two functions for an awarding process: the Selections Process which returns the students that meet the eligibility requirements in a saved Query with optional Ranking and Priority specifications determining the order of the students, and the Results Process which displays Regent calculated awards for those eligible students, tracks against budgets for limited funds, and allows Users to review, edit, and authorize the awards. Setups for existing Fund and Packaging Philosophy configuration options applying to the Fund are used by Regent to calculate the student’s award amount. If no ranking or prioritization was specified, the students will be returned in alphabetical order. Executing the Results Process will finalize authorized awards.

When using the Awarding Tool, the user has the option to Execute, Cancel, or Save a new Awarding parameter set for later use. O An export file containing the returned students and key data elements from the query and ranking setups is available from the Awarding Tool page and the Process Log for use in validating queries or for other purposes. 

We recommend that clients determine what process naming conventions will work best for their shops to make it easier to find specific processes among many that may be saved over time. 

The Results Process tab includes a column for the Regent-calculated ‘Eligible Amount’ for each student returned by the query – these are included in the ‘Total Award Amount’ at the top of the page. The Eligible Amounts are calculated regardless of the remaining budget amount for the fund.  The next column to the right is for the actual ‘Award Amount’ with consideration of whether a budgeted fund has sufficient funds remaining to cover the award.  A student with an ‘Eligible Amount’ who is not high enough on the list to be included in the available budget will have a $0 in the ‘Total Award Amount’ column. Users will edit (if desired) and approve award amounts for finalization. There is an option to approve all listed awards without individual scrutiny and approval. There is also a running total of the Approved Amounts at the top of the page.

Award amounts will include any existing awards of the Fund for the period for the student. Students meeting the eligibility requirements for whom no award is calculated will be displayed with a $0 award amount.  If the student is packaged but the student is blocked from awarding, a $0 amount will be returned.  If packaging fails for the student, the award amount will be blank, not $0.  Budgets from which the students have been awarded will be displayed at the top of the screen with the current balance remaining to offer as well as the amount that will remain after awards selected for Approval on the page are funded. 

Permissioned users execute the Results Process on the Results tab.  Upon execution, awards that have been marked Approved will be added to the student Academic Plan and Award screens with an ‘AT’ icon and any associated budgets will be adjusted accordingly.  Amounts that were edited in the Results screen prior to execution will also have the ‘M’ (manual) icon. The process status will update to ‘Complete’ and the Awarding Tool Results Process Output file, which in addition to the calculated ‘award amount’ contains all packaged awards as ‘amount awarded,’ becomes available via the process log.  If the process will not be fully executed, a user can alternatively elect to Terminate a process, meaning that that process run will not be used to actually award students.  In this case, the process status will update to Terminated.

Please note that the Regent Fund Awarding Tool is not intended for Pell, TEACH, and Direct Loans for which eligibility and awarding are determined by existing federal requirements in the existing Regent configuration and code. Additionally, the Results Process must be completed within 60 days, as the data on which it it based may not be retained past that point.

A Donor Information section has been added to the General tab of Fund Setup. The user may enter information such as name, address, email, and phone number for the fund’s donor.  This information can be accessed via Regent Data Views.

Contact your Account Manager or Product Manager to request more information on Regent Fund’s exciting new fund management toolset. Take control of your eligibility rulesets, explore powerful ranking and prioritization tools, and let Regent handle your award amount calculations while also managing budgets for limited funds. 

Clients have different philosophies about data retention.  Some choose to retain all data ‘forever’, and others chose to destroy files or delete data at some point to reduce the risks of securing the data and/or of having an old record trigger questions or concerns during an audit or review.

Regent 6.0 provides new, configurable full and partial record data deletion options for Regent Review, Regent Award, and Regent Access clients.  A key element is the ‘Record Retention Period’ (RRP). This defines how long certain data will be retained.   Once the Enable Student Record Retention Process has been enabled in Institution Setup, clients specify the number of months in the RRP.  The RRP’s Start Date is set depending on which Regent product is in use, and the RRP End Date is the RRP Start Date plus the number of months configured for the RRP. Only students for whom the RRP End Date has elapsed will have data deleted or purged. Access to these configuration options is permission-based and the options are inherited from Institution to Campus to Site, however the Site can be altered at each of those levels.

For Regent Award clients, the Record Retention Period starts on June 30^th of the last FAY during which the student was in attendance plus one day. There is an option to include students with no attendance and no awards by using the student’s Program Start Date as the Retention Period Start Date. Script RS-22796 should be executed once by Regent Award clients as part of implementation of the data deletion process in order to set the Record Retention Period Start and End dates for Inactive Students.  If this script is not run in Regent Award, students that are Inactive at the time of process implementation will not be eligible for record deletion as they won’t have the necessary retention period data.   

Regent Review (without Award) and Regent Access clients will also run Script RS-22796 on a weekly or some other regular basis to set the Record Retention Period Start Date for June 30^th of the latest ISIR or FAY-based document for the student, plus one day.  Records are not eligible for deletion until the Retention Period has elapsed. 

The Student Summary tab will display the following new fields for each student if the Enable Student Record Retention Process has been enabled:  Record Retention Period Start Date, Record Retention Period End Date, Record Deletion Date (if only partial records were deleted). The Record Retention Period End Date is calculated by Regent as noted above, but it can be edited manually by permissioned users.  Any such modification will result in an Activity Log Entry.  A data deletion process will include only students for whom the greater of the system-calculated or manually entered Record Retention Period End Date has elapsed.

A new Record Retention/Deletion Process under the Processes tab has two subprocesses: Export Record Deletion List and Execute Record Deletion Process. Users review the Record Deletion List, and if all is satisfactory, can then initiate the Execute Record Retention Process to delete data for the students on the list.

The user will select which institutions, campuses and sites are to be included in the Export Record Deletion List, as well as the Maximum Retention Period End Date.  Requesting the ‘Export Record Deletion List’ will create an Export Record Deletion List process log entry that includes a CSV output of the students meeting the specified criteria for whom the Record Retention Period End Date is before the Maximum Retention Period End Date.  The list will contain an indicator if the student’s Retention Period End Date was set manually.

The Execute Record Deletion List process allows the user to select a recent Export Record Deletion List for use in the record deletion process.  Run-time parameters include an option to delete full Student Records, or to Delete All but Specific Student Data.  If the full Student Records option is not selected, the user is provided with options on what data is to be retained to include: Basic Bio/Demo data, SAP History, Full Document History, or only Selected Documents. The user selects the Record Deletion List from among the five most recently produced lists, and then must type in ‘DELETE’.  After additional warnings that this process cannot be undone, the removed data will be unrecoverable, and confirmation that the process was tested in QA, the user will type DELETE in the specified field and then click the ‘Delete’ button. A second message will ask for confirmation of the intention to delete the data, with options to confirm by clicking ‘yes’ or to cancel the process.  The process will run, and all specified data will be permanently deleted.

It is critical to test the deletion process in an updated QA instance before running it in Production by running an Execute Record Deletion List and Execute Record Deletion List process with the same criteria you plan to use in Production and confirming that the results are as expected.

The Process Log entry will include a file that lists the ExternalID1 of all students in the selected Export Record Deletion List, the student’s name (unless all student data was included in the deletion process), and a message that the Full Student Record from the list {<Process ID> was deleted, a Partial Student Record was deleted, or the student was not deleted because the student’s Record Retention Period End Date had subsequently been modified to a future date. Students with partial data deletion are automatically flipped to ‘Inactive’ status, if they are not already in that status.  While a fully deleted record will not result in a student Activity Log Entry (because the Activity Log will also have been deleted), a partial deletion will be memorialized with an Activity Log Entry

Over the last several releases, Regent has been working to provide standardized communication options to reduce the need for custom requests by clients.  To this end, standardized filters and standardized templates have been made available.  The main client resource for these is Standard Communication Body Templates and Filters. Clients will be able to use the same standard filter for both e-mails and texts. If you wish to use one of the standard texts, Regent recommends also using the more detailed e-mail communications to provide more information on the related topic.

For information on setting up standard communications for testing and production, please see Configure a Communication. If you already have customized communications for certain topics, there is no need for you to switch to the standardized versions.

With Regent Release 6.0, clients can now control where different Student Experience components display in the Menu order and on the student dashboard. 

Using Up/Down arrows on the General Tab in Portal Configuration, the user can configure the order in which the different enabled Student Experience components will display in the Student Experience Menu.  The available components are Useful Links, Communications, Financial Aid, SP Progress Disb (Subscription Period Disbursements), SAP, Documents, Regent Plan and Help.  Note that all enabled components will display in the menu, but users can elect to exclude one or more of them from the dashboard display.

The dashboard sort order configuration option in the same section works similarly for users to specify which components will display on the Student Experience dashboard, as well as the order in which the Student Experience component tiles will display. Desktop ordering will be first from left to right, and then from top to bottom.  For example, if ordering components to display in the following order:  Financial Aid, Satisfactory Academic Progress, and Useful Links, Financial Aid will display at the top left corner of the dashboard, SAP at the top right, and Useful Links at the bottom.  Mobile display ordering is from the top to the bottom.

IMPORTANT NOTE: Be sure to configure the components you want your students to see in Student Experience as you upgrade to 6.0.

Regent is pleased to provide a new, highly configurable Student Experience component to display student’s current SAP status.  If electing to use this option, a client may configure the SAP Display Name the student will see on the menu and dashboard.  Other configurable elements include the standard instructional message header, an instructional message for the component, messaging if the student has a ‘Not Calculated’ SAP status, and informational messages that will display depending on the student’s current SAP status of Satisfactory, FA Warning, FA Probation, FA Suspension, or MTF Suspension.  Other display options include a link to display the student’s current SAP policy requirements along with the options to display the student’s SAP GPA, the completion rate/pace and/or the student’s Maximum Time Frame status, each with configurable labels.

The SAP tile will display the student’s current SAP status.  The student will access the SAP component screen via the SAP option on the Menu or by clicking on the ‘Review Satisfactory Academic Progress Details’ link in the SAP tile on the dashboard.  Once accessing the SAP screen, the student will see the configured Display Name, Instructional Message header and text, the current SAP status in green, yellow, or red based on severity, the SAP Status effective date, the configured Informational Text for the student’s current SAP status, and, if configured, the SAP policy requirements and the student’s current standing for GPA, completion rate/pace, and Maximum Time Frame.  Each of the labels for the last 3 items is configurable.

Student Data Updates:  If the new ‘Allow Personal Information Updates’ option is selected on the Access General Settings tab, when a Smart Form is completed, it will be checked to compare the student’s First Name, Last Name, Student Date of Birth, and SSN/DACA/ITIN, against current Regent data.  If there are differences, those data fields will be updated in the Regent database to reflect the Smart Form information.  The changes will be displayed in the Student Experience Profile as well as in the Summary and Student Details tabs within Regent.  An aligning Activity Log Entry will document the change. 

New Export File Process: A new process type of ‘Export Access Database Extract File’ is presented to Access users in the Export Processes selection list.  This process will generate a file with the data from the Access Smart Forms and can be scheduled to either run regularly or be kicked off as needed.  Selection parameters allow users to select only those applications that have been signed, whether to include dependency status in the output, and whether all applications will export or if the file should only include those applications created or modified since the last export. The process will use the client’s existing SFTP folder for the SNAP Application Export Process

Student Edit Capability: A configuration option will allow clients to provide students with edit capability for Access applications that are in ‘Satisfied’ status.  If the student makes edits, a new document with the student’s edits will be created with an incremented transaction number.  The transaction number will be included in the document tile as well.  No new parent signature will be required for Dependent students unless Parent Information is changed.

Student E-mail Addresses:  Student e-mail addresses from Student Experience Account Registration and from Smart Forms in Student Experience will be persisted and viewable on the Student Details Contact Information section in Regent if a matching e-mail for the source type does not already exist.  These will show source types of ‘Portal Registration’ or ‘Smart Form’ respectively.

Master Questionnaire Updates: Two updates were made to the Regent Access Master Questionnaire (Smart Form Type of ‘Financial Aid Application’) for 2022-2023 (in use in the Student Experience portal.)  The highest selection value for the ‘Student’s Number in Household’ was increased from 14 to 20, and the default value for both the Parent and Student ‘Residency before MM/DD/CCYY’ questions was removed.

A new Display ‘Office Use Only’ Documents option has been added to the Salesforce tab under Institution Setup.  If elected the ‘Office Use Only’ indicator will be included for affected documents in the Regent Award for Sales Force application.  Please note that a Salesforce upgrade is required for the new indicator to be included in the application, but no Salesforce upgrade is required to maintain current functionality upon upgrade to Regent Release 6.0.

Upon upgrade to Regent Release 6.0, document requirements can be configured for assignment by program.  Note that this option will only function with document requirements with packaging-related triggers, and not for documents triggered by ISIR imports. The user will access the Packaging Assignment tab in Document Setup to configure the document requirement to trigger during the packaging process if the student is in a selected program, a selected fund (existing option), or if the student is in a selected program and is packaged with a selected fund. The document requirement will be assigned if the student is being packaged for a current or immediate future scoped period if the document requirement does not already exist.