The initial processing task is to apply Progression Rules to all those Student Course Attempts that are ready to be checked. This is done through the job PRGJ6100 (Apply Progression Rules). This job should be scheduled to run at regular intervals throughout the Progression Evaluation Period. Job parameters should be used to process students in the most appropriate way for an institution. For instance the job may be scheduled to run consecutively, with a different Organisational Unit parameter setting. This processing of students in groups based on Organisational Unit, may be a useful way to produce exception reports appropriate to different progression review panels in the institution.

Generally this process would not require parameter settings to limit processing to a particular Progression Period. The relevant Progression Period/s are determined based on the structure established when the Progression Subsystem was configured and Calendars set up. Those Student Course Attempts that require evaluation within this period (and are ready to be tested, based on the configuration applicable) are identified and each applicable rule is tested.

The Exception Report can list either those who failed rules or all tested students (a parameter selection). The default setting lists only those who fail a Progression Rule. Where required the report from a previous running of the job can be reproduced with this setting reversed.

This report describes, for each Student Course Attempt and rule tested, the Outcome of the rule check and the action taken as a result. It also provides a summary of the number of students tested and the numbers who fail Progression Rules. It can be used in preparation for Progression Review Panel meetings. For example from this report staff can identify those students whose lack of progress is so severe that the panel may require additional information on which to base a decision about recommended Progression Outcomes (such as producing an Academic History)

Example:
Against STUDENT ID 99ABC (who passed all tested rules) the message 'All tested rules were passed' is reported
Against STUDENT ID 99DEF (who failed a Progression Rule) the message 'Rule(s) were failed. The following recommended Outcomes were added.' is reported.
Against STUDENT ID 99GHI (who failed a Progression Rule) the message ''Rule(s) were failed. The following automatically approved Outcomes will be applied.' is reported.

The result of this process will be a group of students who are making progress (and continue to have a Progression Status of GOODSTAND such as Student 99ABC) and a group who are not (e.g. Students 99DEF and 99GHI). This process creates one or more student Progression Outcomes for those students in the second group.

The students who have failed one or more Progression Rules may require further action, depending on the settings associated with the Outcome added to the Student Course Attempt. Some Progression Outcomes may be set to apply automatically to the student - that is the student Progression Outcome is created with a decision status of APPROVED. It will be applied when the job PRGJ6800 is subsequently run, without any further action required (unless a decision is taken to reverse this Outcome).

Where a Show Cause Period is allowed (through the configuration applicable to a student) the Show Cause Expiry Date is derived and the student will have a Progression Status of SHOWCAUSE. Where there is no available Show Cause Period, the Progression Status reflects the approved Outcome (for example, SUSPENDED). (Where an appeal period is available, the Appeal Expiry Date is derived but the Progression Status reflects the approved Outcome or the availability of a Show Cause Period.)

The second group is those who've failed more serious Progression Rules with associated Outcomes that are not set to apply automatically. Student Progression Outcomes of this type are created with a PENDING decision status. These require further action before they can be applied. A student in this group would have a Progression Status of UNDCONSID. Student 99DEF is from this group.

Reviewing Student Progression Outcomes Added After Failing a Progression Rule

The next task is that those who have pending Outcomes, after the application of rules, be reviewed and a decision made to either approve or waive that Outcome. The form PRGF6700 - Maintain Progression Outcome Decision is used to both assist this process and record the final decision, for multiple students.

In this form Student Course Attempts with pending Progression Outcomes can be retrieved based on criteria entered by the user. The criteria options include Organisational Unit, Progression Period, Course Type, Course Code, Location and Attendance Mode.

To assist the decision-making process, a recommended decision (Approve or Waive) is selected for each Outcome. Details of the rule application and the resulting Outcome under consideration can be viewed using overlay screens. The recommended decision can be accepted or altered as required.

When each record has been reviewed and the agreed decision status set, all records can be updated through the use of the Process command button. Those that have Outcomes approved may have their Progression Status updated. This can be to SHOWCAUSE where configuration applicable to the student allows a Show Cause Period and it has not expired. Where Show Cause is not available it updates to a status that reflects this Outcome, unless a more severe approved Outcome already exists for this Student Course Attempt. Those where the Outcome was waived will have their Progression Status restored to its previous setting (where no other Outcomes are pending or active the status becomes GOODSTAND).

Example:

The decision is made (and recorded in this form) to approve the recommended suspension for Student ID 99DEF (as part of approving or waiving Outcomes for a larger group of students). This student is allowed a period in which to Show Cause, so her Progression Status becomes SHOWCAUSE, until the expiry of that period (calculated as being 14 days after this Outcome was approved).

Recording a Decision on a Show Cause Submission

The viewing and recording of Show Cause details must be done for an individual student Progression Outcome, through form PRGF6610 (accessed via PRGF6600, where the Student Course Attempt is retrieved). Use this form to override the Derived Expiry Date for this Show Cause Period if required (for example where the derived period allowed is too short for the student to be able to make a submission). It is also used to record both that the student made a submission and the decision reached on that submission.

Where the submission is dismissed, this Approved Outcome can now be applied (either immediately using the Apply command button on this form or as part of a batch applied through the next run of the job PRGJ6800). The student's Progression Status will update from SHOWCAUSE to the relevant status for the Outcome.

Example:

Student ID 99DEF made a submission within the allowed Show Cause Period, but the review panel dismissed it. The decision to dismiss the submission was recorded on the system (but the Outcome was not manually applied). Student ID 99DEF's Progression Status automatically updated to SUSPENSION. The Outcome will be applied when PRGJ6800 is next run.

Applying Student Progression Outcomes

The next major task required is the application of Approved Outcomes. This is done through scheduling the job PRGJ6800 - Apply Progression Outcomes.

prgpic10.gif

This job should be scheduled as a regular nightly job. It will apply all APPROVED Outcomes that do not yet have an applied date set. The type of Outcome being applied determines the action taken (for example whether a person Encumbrance is created and whether the Student Course Attempt is discontinued). This is described in the documentation for the job. Where possible (and relevant) an Expiry Date for the Outcome (and any associated Encumbrance) is derived.

Some Progression Outcomes (and their associated Encumbrances) cannot have a Duration/Duration Type specified and therefore cannot have a derived Expiry Date. These are Outcomes with a System Type of EXCLUSION, EXPULSION or NOPENALTY. An Outcome of this sort must be manually expired.

This job checks for the existence of a Show Cause and/or Appeal Period that may delay the application of this Outcome. This occurs where the configuration settings do not allow an Outcome to be applied before a Show Cause and/or Appeal. If a relevant period is currently available to the student, the job does not apply the Outcome. Instead that student record remains as an APPROVED Progression Outcome to be applied subsequently, after the Show Cause or appeal period is completed. These periods are considered completed when either the student's submission has been dismissed and that decision has been recorded or when the Expiry Date of the period has passed without any submission being made.

The Exception Report produced can be used to identify those Outcomes that could not be applied. The cause of these errors is described in an explanatory message. The most common cause of errors is where the process attempts to apply an Outcome with associated Encumbrance effects that clash with an existing Outcome for the same student. The process resolves some clashes by expiring the existing Encumbrance then applying the new. Those that cannot be resolved are not applied and are reported as errors. These Outcomes remain as APPROVED and the clash must be resolved manually. In reviewing the errors and determining subsequent action, the possible actions that may be taken are to expire the existing Outcome (and then apply the new) or to waive the new Outcome and allow the existing Outcome to remain in force. Both can be done through form PRGF6610 (navigate to this form from PRGF6600 after retrieving the required Student Course Attempt).

Clashing Encumbrance Effects

This job also lifts an Encumbrance and/ or Discontinuation from a student where a previously applied Progression Outcome has been cancelled.

Recording the Decision on a Student Appeal

The viewing and recording of appeal details must be done for an individual student Progression Outcome, through form PRGF6610 (accessed via PRGF6600, where the Student Course Attempt is retrieved). Use this form to override the derived Expiry Date for this appeal if required (for example where the derived period allowed is too short for the student to prepare an appeal). It is also used to record both that the student did appeal and the decision reached after the appeal was heard. The standard (and default configuration) would be for an appeal period to occur after a Progression Outcome has been applied. The following explanation assumes that this is the case.

Where the appeal is dismissed, this applied Outcome remains in force. The student's Progression Status remains set to the relevant status for the Outcome.

Where the appeal is upheld, the decision status for the Outcome must be set to CANCELLED. The student's Progression Status reverts to the status that applied before this Outcome was approved (GOODSTAND unless another approved Outcome exists). The Outcome can be lifted immediately by using the Apply command button on the form, or it will be lifted in the subsequent running of the job PRGJ6800.

Processing a Student Course Attempt Manually

Forms PRGF6600 and PRGF6610 are used to perform all of these processes manually, for a single Student Course Attempt. The processes function in the same way as when run using the jobs and bulk form, but act on a single record.

Changing the Decision Status of an Approved And/Or Applied Outcome

There may be circumstances where the decision is made to revoke an already approved Progression Outcome. This can be done for a single student, using form PRGF6610 (accessed through PRGF6600). A Progression Outcome that has been approved but not yet applied can have the Decision Status reset to PENDING or WAIVED. An Outcome that is reset to pending will be re-presented whenever the bulk approval form (PRGF6700) is used to retrieve records awaiting a decision. Waiving the Outcome means it will not be re-presented for consideration.

An Outcome that has been both approved and applied must have the Decision Status set to CANCELLED. The subsequent running of PRGJ6800 processes this cancelled decision status and lifts associated Encumbrances.

Manually Expiring an Applied Outcome

Some Outcomes cannot have an Expiry Date derived (as they have no duration values) and must be expired using form PRGF6610. Entering an Expiry Date against the Progression Outcome (rather than the method described above where the decision status is altered) would usually be the better method. The decision status then accurately reflects the decisions that were made in relation to this student Progression Outcome - it was not cancelled, it has expired.

This method can also be used to expire an existing Outcome to allow the application of another incompatible Outcome.

If required, the Expiry Date for a Student Progression Outcome application can be manually back-dated (in PRGF6610) to a date that is greater than or equal to the Encumbrance Start date and less than or equal to the current date.

If the Expiry Date of a Student Progression Outcome Application is updated and applied (via the Apply button in PRGF6610), any associated Person Encumbrance and Encumbrance Effect Expiry Dates in ENRF6320 (or Academic Encumbrances) are automatically set to the same value as the Expiry Date in PRGF6610 for the Outcome application.

Note: An Expiry Date that was manually applied to an Outcome (in PRGF6610) can subsequently be deleted (ie. set to NULL), for example, if you want to make the Encumbrance ACTIVE.

Creating a Progression Outcome Unrelated to a Rule Failure

Non-rule related Outcomes are created in form PRGF6610, accessed from PRGF6600 using the Manual Outcome button. The situations that prompt the application of a Progression Outcome unrelated to Progression Rule failure will vary from institution to institution. Academic Encumbrances can only be applied through the Progression Subsystem. Where an Encumbrance of this type is required (but unrelated to failing a Progression Rule) this method can be used to apply one.

Once created, these Outcomes can be updated and applied either in these forms or through the bulk processes described above.

Evaluating Course Completion and Graduation Eligibility

Completion rules can be created for Unit Sets, Course Stages and Course Versions. The progression Subsystem provides a means to evaluate a Student Course Attempt against all three completion rules. This is done through the form PRGF9030 - Inquire on Student Completion.

This form allows rule checking to be run in Standard Mode - testing whether a student has completed requirements. It can also be run in Predictive Mode based on both current enrolled and already completed units. The result of the rule check displays on the form.

This can be used as one of the measures on which an institution can base its decision to classify a Student Course Attempt as complete. This testing of Completion Rules does not automatically flag the Student Course (or Unit Set) Attempt as complete. The process of setting the Completed indicator (on ENRF3252) against a Unit Set should follow the testing of a Unit Set completion rule, where a student satisfies the academic requirements of that Unit Set.

To mark a Student Course Attempt as complete, the Rqrmnts Complete check box must be set in PRGF4170, after an institution's has determined that academic requirements and other obligations have been satisfied. The setting of this check box marks the student eligible to Graduate from that Course Version.

Last Modified on 29-Oct-2010 3:08 PM

History Information