Progression Specialist Functions

Progression - Specialist Functions

In this section:

Setting Up the Progression Subsystem

Setting Up Progression Outcome Types & Encumbrances
Progression Configuration
Configuration Tasks
Setting Up Progression Date Aliases

For System-wide Configuration
For Override Configuration

Setting Up Progression Calendars

Relationships Between Progression & Other Calendars
Associating Progression Calendars with Configuration Levels

Calendar Stream Numbers

Setting Other Progression Configuration Parameters

Show Cause & Appeal Parameters

Other Specialist Issues

Setup for Existing Student Course Attempts
Modifying the Progression Structures
Calendar Rollover
MDL Views which Support Progression

This document is written for specialist Progression staff with responsibility for setting up and maintaining the Subsystem. The following is assumed:

An understanding of the information provided in Understanding Progression
A working knowledge of the Calendar and Rules Subsystems.

The specialised area of creating rules for Progression is described in other documents:

Progression Rules and Completion Rules Overviews

Setting Up Progression Outcome Types & Encumbrances

Reference Data	Purpose	Optional?	Maintenance Form	Setup Dependencies
Progression Outcome Types	Applied to a Student Course Attempt, as the outcome of failing a Progression Rule	No - must exist before creation of Progression Rule Outcomes	PRGF1100	Encumbrance Types ENRF6200 System Encumbrance Effect Type ENRF6100

Progression Outcome Types must be created to allow their use in the definition of a Progression Rule Outcome. A Progression Outcome is the result applied to a Student Course Attempt when a Progression Rule is failed. Some Outcomes may have no penalty - their purpose is as a warning that current progress is of concern. The penalties that can be applied are of two types (not mutually exclusive) - an Academic Encumbrance that applies to a Student's Enrolment and a Discontinuation (of Course, Unit Set or Unit Enrolment).

In creating the institution's Progression Outcome Types each is linked to a System Progression Rule Outcome Type and to the Encumbrance and Encumbrance effect (where applicable). The link to a System Type determines the 'penalty' as each System Type has specific allowable Encumbrance and Encumbrance Effect Types. The PRGF1100 documentation provides a table of the allowable Encumbrances for each System Outcome Type.

In use, some outcomes may not be applied together as the effects clash. These clashes are described in Understanding Progression.

Progression Configuration

Configuration at Different Levels Within an Institution

Institutions require a flexible System to measure the progress students are making in their studies. One means of providing this flexibility in the Progression Subsystem is through the different levels at which the Subsystem can be configured.

The Progression Subsystem within Callista must be configured at a System-wide level. These configuration settings become the defaults, which apply across the institution, to all Student Course Attempts, unless overridden. Different configuration options can be set at the Organisational Unit and/or Course Version level.

Where Progression is configured for an Organisational Unit, these settings override the System-wide settings, for students within that Organisational Unit.
Where configuration parameters are set at a Course Version level, these settings override the System-wide (and Organisational Unit level settings if they exist), for students within that Course Version.

Configuration for a Course with Joint Ownership:

Where a course is jointly owned and the 'owning' Organisational Units have been configured differently, Progression functionality uses the configuration of the Organisational Unit entered as the Responsible OU in the Course Details form (CRSF1210). An institution with a number of courses of this type may find it appropriate to explicitly configure the Course Version.

prgpic1.gif

When configuring the Progression Subsystem, institutional policy and practice regarding Progression must be clearly identified. (Where Organisation Unit and/or Course Version level configuration is to be implemented, variation at the Organisational and Course Ownership Levels must also be clearly identified). These issues are more broadly discussed in Understanding Progression, but the following have particular implications for configuring the Subsystem.

Is configuration required only at the System-wide level or do Organisational Units / Course Versions require different configuration?
The periods of time at which the institution carries out Progression Checking - for example, there may be a need for both Semester and year-long Progression Periods; some institutions may also require Trimester Progression Periods.
Institution policy regarding the provision of a Show Cause and/or Appeal Period (allowing students who fail any Progression Rule Check to appeal against the imposition of penalties). If these are not allowed at the institution-wide level, are there Organisational Units that allow Show Cause or appeal, either for all students studying all courses offered by the Organisational Unit or those studying a particular Course Version?

The timing of the application of outcomes resulting from failure of a Progression Rule Check is a related issue. Are these to be applied before a student shows cause/appeals or after these processes have been completed?

Are time periods on Suspension/Exclusion to be counted in time calculations (e.g. related to completion of course within an allowed time)?
Are Weighted Average Mark and/or Grade Point Average values to be calculated for all Student Course Attempts, irrespective of their use in Progression Rule evaluation?

Configuration Tasks

The following sequence of tasks must be performed to configure the Progression Subsystem, at a System-wide level:

Create the required Progression Date Aliases (using CALF0420).
Create the required Progression Calendar Types and Calendar Instances for each type (using CALF0220).
From CALF0220, establish the required Calendar Instance Relationships (CALF0330) and Date Alias Instances (CALF0512 or CALF0511).
Configure the System Progression parameters - Date Aliases, Show Cause / Appeal parameters and Other parameters - using PRGF2100.
Select the Progression Calendar Types that are to apply at the System-wide (default) level and set their required parameters, using the Progression Calendar overlay in form PRGF2100.

Any Organisational Unit or Course Version that requires different configuration from that set for the whole institution must be configured in the appropriate form. For Organisational Unit configuration, use PRGF2300. For Course Version configuration, use PRGF2200.

Setting Up Progression Date Aliases

The cycle of applying Progression Rules and Outcomes is controlled by the existence of instances of Date Aliases within the Progression Calendar. For example, the date on which Progression Rule Checking is to start is controlled by the existence of a Progression apply Start Date Alias. Using the example in the diagram below for a Semester 1 Progression Period, rules cannot be applied until the current date matches an instance of the apply Start Date Alias (labelled SA).

prgpic4.gif

Legend:

Date Aliases	Meaning	Actions	Meaning
SA	Start of automatic testing against the applicable Progression Rules	1	A Progression check is done and the student fails the rule. An outcome is recommended. The student's Progression status is automatically updated to UNDCONSID
SC	Show Cause period cut off Date Alias - date beyond which system cannot allocate a derived Show Cause period finishing date. Similarly, an entered override cannot extend beyond this.	2	The outcome is approved and the available Show Cause period begins. The student's Progression status is automatically updated to SHOWCAUSE.
EA	End date of automatic testing, for the first time, against a Progression Rule.	3	The Show Cause period for this student ends; he did not Show Cause. The student's Progression status is automatically updated to reflect the Progression Outcome (e.g. SUSPENSION). The outcome can be applied.
AP	Appeal period cut off Date Alias - date beyond which system cannot allocate a derived appeal period finishing date. Similarly, an entered override cannot extend beyond this.	4	The Appeal period begins. The student's Progression status is unchanged & reflects the Progression Outcome (e.g. SUSPENSION).
EP	Last date on which Progression penalties can be automatically applied, as a result of re-testing of a rule (e.g. where a student's result was amended)	5	The student appeals against the penalty.
EB	Last date on which Progression penalties can be automatically lifted, as a result of re-testing of a rule (e.g. where a student's result was amended)	6	The appeal is upheld and the penalty lifted. The student's Progression status is restored by the system to GOODSTAND.

Note the Progression Statuses are System Statuses. They are updated as the result of Progression Rule evaluation, the approval of Progression Outcomes added to a Student Course Attempt as the result of failing a Progression Rule, the availability of a Show Cause period and the application or cancellation of a student Progression Outcome.

Date Aliases for System-Wide Configuration

There must be at least one set of the following Date Aliases created, for use as the default configuration of the Progression Subsystem.

These institution-defined Date Aliases are created using CALF0420 and can then be assigned as part of the System (default) Progression parameters, configured in PRGF2100. In this form, each Date Alias is linked to the appropriate System parameter. The additional parameters that must be configured in this form are described below.

Date Alias to Represent:	Optional?	Example	Links to System Element (in PRGF2100)
An Effective End Date for a Progression Period. Where a unit could potentially contribute to more than 1 Progression Period (in a stream) a Student Unit result entered on or before an instance of this date identifies the unit as contributing to the applicable Progression Period. It will be included in Progression Rule Checking for that period. Units discontinued on or before this date are considered to contribute to this period only where the associated Administrative Unit Status is one that is 'effectively enrolled for Progression'. (See ENRF0110)	No	PRG-EFFECT	Effective End Date Alias
The Start Date for the automatic application of Progression Rules to any Student Course Attempt not previously checked in this Progression Period.	No	START-APPL	Apply Start Date Alias
The end of the automatic initial application of Progression Rules to a Student Course Attempt. (Subsequent changes to a course attempt, such as amended grades, trigger rechecking).	No	END-APPL	Apply End Date Alias
The last date on which, as the result of a 2^nd or subsequent Rule Check in a Progression Period, the student's Progression Outcome and status can be automatically altered, to his/her benefit. For example an amended grade is entered, the Progression Rule re-checked and the student now passes a previously Failed Rule. The previously applied Outcome is automatically removed only if the check occurs before this date.	No	END-BENF	End Benefit Date Alias
The last date on which, as the result of a 2^nd or subsequent Rule Check in a Progression Period, the student's Progression Outcome and status can be automatically altered, to his/her detriment. For example an amended grade is entered, the Progression Rule re-checked and the student now fails a previously passed rule. The outcome of failing this rule can be automatically applied only if the check occurs before this date.	No	END-PEN	End Penalty Date Alias
This date is used in the derivation of Expiry Dates for Progression Outcomes and associated Encumbrances. Instances of this may be set to a date earlier than the end date of the Progression Period, to allow Expiration of Encumbrances prior to enrolment starting for a subsequent Teaching Period. Where it does not exist, the Calendar End Date is used instead.	No	ENCUMB-END	Encumb End Date Alias
The last date (for a Progression Period) beyond which a Show Cause Expiry Date cannot be System derived. Refer to the Show Cause & Appeal Parameters topic.	Yes - defined only when the institution (or a subset of the institution) allows a Show Cause period	SHOWC-END	Show Cause Cut Off Date Alias
The last date (for a Progression Period) beyond which an Appeal Expiry Date cannot be System derived. Refer to the Show Cause & Appeal Parameters topic.	Yes - defined only when the institution (or a subset of the institution) allows an Appeal period	APPL-END	Appeal Cut Off Date Alias

Date Aliases for Override Configuration

Additional Date Aliases can be created to represent each of the same elements (excluding the Effective End & Encumb End Date Aliases, which are only required at the System level), for override configuration at an Organisational Unit or Course Version level. For example, a particular faculty may require a different Progression application cycle from the rest of the institution. To allow this, either all or some new Date Aliases can be defined, so that the Progression cycle for that Organisational Unit can be configured differently.

An Example:

System Configuration Date Alias	Org Unit Date Alias set. (Some in the set are new, created to Override System Progression configuration for the Engineering School, some are existing System Date Aliases)	Course Version Date Alias set. (Complete new set created to Override System & Organisational Unit Progression configuration for Course Code: S306 - Bachelor of Engineering)
START-APPL	START-APPL (System Date Alias reused)	START-S306
END-APPL	END-APPL (System Date Alias reused)	ENDAP-S306
END-PEN	ENDPEN-ENG	ENDPN-S306
END-BENF	ENDBF-ENG	ENDBF-S306
SHOW-END	SHOW-ENG	SHOW-S306
APPEAL-END	APPEAL-END (System Date Alias reused)	APPEAL-S306

The Organisation Unit configuration (linking the Date Aliases to the appropriate System elements) is done using PRGF2300. The Course Version configuration is done using PRGF2200. If an Organisational Unit or a Course Version is configured for Progression, all Organisational Unit/Course Version Progression Configuration settings must be defined.

Setting Show Cause or Appeal parameters can only be done where the System level configuration allows these periods.

Setting Up Progression Calendars

The linking of Progression Calendars to other components of the Progression structure controls the application of Progression Rules. One or more Progression Calendar Types must be linked at the System configuration level and can be linked to other levels. One or more Progression Calendar Types must be linked to each Progression Rule application (where a rule is linked to a System element such as a Course Version). The linking of a rule to a Progression Calendar can be done at any level in the rule application hierarchy (described in the Progression Rules Overview).

A Calendar Type (with the Calendar Category of PROGRESS) should be created for each Progression Period to be used within the institution. For example an institution may require a Calendar structure which has Progression Periods for two Semesters and an Annual Period. This would allow Progression checking to be carried out on a Semester-by-Semester basis or on a year-long basis, depending on the requirements of different groups within the institution.

Instances of each Calendar Type are created in CALF0220, by defining the Start and End Dates, status and an alternate code for each instance. Alternate codes are required for Progression Calendars as they are used to identify these Calendars in forms and on exception reports (e.g. the Student Progression Rule Check form - PRGF6600).

Relationships Between Progression & Other Calendars:

Relationships between the Progression Calendars and their allowable superior and subordinate Calendars are established, using CALF0330. Calendars of the Calendar Category PROGRESS can have the following valid relationships with other Calendar types:

Valid Relationship to PROGRESS Calendar Category	Calendar Category	Reason
Superior Calendar:	Academic	Mandatory
Subordinate Calendars:	Teaching	A Progression Calendar must have a link to at least one teaching Calendar. To link the set of Teaching Periods over which a given unit is studied and assessed, to one or more Progression Periods.
	Load	A Progression Calendar can have a single subordinate load Calendar. This may be an aggregate load Calendar. Required where Progression Rule applications are restricted to an attendance type and where a Progression Rule outcome applies an attendance type or credit point restriction. To allow the derivation of a student's attendance type within a given Progression Period. To allow the definition of Progression Rules that apply to a given attendance type.

An Example - Calendar Relationships:

prgpic2.gif

Note: A = the 'Effective End' Date Alias for the Progression Period. It is used to determine in which Progression Calendar a unit discontinuation or other form of early result is considered, where a unit is studied in a Teaching Period that is linked to more than one Progression Calendar (for example S1-E1 and S2-E2 Teaching Calendars in this diagram).
Arrows represent the defined Calendar relationships.

After establishing the required Progression Calendars and relationships, the Calendar Quality Check (CALR0100) report should be run to ensure that these Calendars and relationships satisfy quality checks.

Associating Progression Calendars with Configuration Levels.

Progression Calendar Types are selected as part of System-wide configuration of Progression, using PRGF2100. All Progression Calendars that are used widely across the institution can be associated at this System level. For each selected Calendar a Stream Number, a Show Cause and an Appeal Length value is recorded, which configures the Calendar for System-wide use. These values are used in deriving Expiry Dates for Progression Outcomes (& associated Encumbrances) and Show Cause or Appeal Periods. All Organisational Units and/or Course Versions can inherit these Calendars allocated at the System configuration level.

However where either an Organisational Unit or a Course Version requires some variation from the System Calendars, it can have Progression Calendar Types allocated as part of configuring Progression. This can be done using the configuration forms (PRGF2300 for an Organisational Unit or form PRGF2200 for a Course Version). This may be done where a different Progression Calendar from any linked at the System level, is required. For example, System configuration has 2 Semester-length Calendars linked, but an Organisational Unit requires a year-long Calendar. It may also be required because one of the Show Cause or Appeal values for an existing System Calendar needs to be varied for an Organisational Unit or Course Version. For example an appeal length of 14 days is set at the System level, but for a particular Course Version this must be 21 days.

Example: The System Progression configuration has a Semester 1, Semester 2 and a year-long Progression Calendar selected and configured as shown. An Organisational Unit that offers courses to non-award students requires only a year-long Progression cycle, allows no Show Cause Period and a shorter Appeal Period than that provided for other students under the System-wide year-long Progression Calendar.

System Configuration Calendars Selected:	Calendar Settings
Semester 1 & 2 Progression Calendars (both have the same settings)	Stream No. 1 Show Cause Allowed Show Cause Length = 14 days Appeal Allowed Appeal Length = 14 days
Year length Progression Calendar	Stream No. 2 Show Cause Allowed Show Cause Length = 14 days Appeal Allowed Appeal Length =21 days
Org. Unit Configuration Calendar selected:
Year length Progression Calendar	Stream No. 2 Show Cause Not Allowed Appeal Allowed Appeal Length = 14 days

Stream Numbers

Calendar Types that represent a logical sequence of Progression Periods are identified through being given the same Stream Number, in these Calendar configuration forms. The Stream Number is used in the derivation of Expiry Dates for Progression Outcomes and associated Encumbrances. In the example above, the Semester length Progression Calendars have a Stream Number of 1. An outcome applied in a Semester 1 Calendar (with this Stream Number) and set to remain in force for 2 Progression Periods will expire at the Encumbrance End Date Alias Instance in the 3^rd Semester. The same outcome applied in the 1^st year under a year-long Progression Calendar with a Stream Number of 2, will expire at the Encumbrance End Date Alias Instance in the 4^th year.

The same Stream Number must be allocated to the same Progression Calendar Type even when it is linked at different configuration levels. For example a Progression Calendar allocated the Stream Number of 1 at the System-wide configuration level must have the Stream Number of 1 allocated when it is used in configuring either an Organisational Unit or a Course Version.

Setting Other Progression Configuration Parameters

In addition to configuring Date Aliases and Progression Calendar Types, the following parameters set at the System Level become the default configuration. Where they are also configured at an Organisational Unit or Course Version level, the system settings are overridden for students enrolled under that Organisational Unit/Course Version.

Parameters	Purpose
Outcome Check Type	Determines the type of Student Unit Attempt outcomes that must exist, before Progression Rule evaluation can begin. The three possible types are: MISSING (allows Rule Checking where some Unit Attempts do not have outcomes recorded). RECOMMEND (allows Rule Checking where there is a mix of recommended and finalised Unit Attempt Outcomes recorded). FINALISED (allows Rule Checking only where all Unit Attempts have finalised outcomes recorded).
Show Cause check box Apply Outcome Before Show Cause check box	Indicates that a Show Cause Period is available. Indicates that approved Progression Outcomes can be applied before the Show Cause Period ends. Default is No at all levels. If the Show Cause check box is not selected, no other parameter relating to Show Cause can be set.
Appeal check box Apply Outcome Before Appeal check box	Indicates that an Appeal Period is available. Indicates that approved Progression Outcomes can be applied before the Appeal Period ends. Default is Yes at System level, No at other levels. If the Appeal check box is not selected, no other parameter relating to Appeal can be set.
Count Suspension in Time check box Count Exclusion in Time check box	Specifies whether Suspensions/Exclusions are counted in time calculations.
Calculate WAM check box Calculate GPA check box	Setting these check boxs allows an 'on-the-fly' calculation and display of the current GPA or WAM value, on forms INQF1200, ENRF3000 and the Academic History report (ENRR08M0). It also indicates that whenever Progression Rules are applied to a Student Course Attempt, the indicated value is calculated, stored and displayed (in the context of the applicable Progression Period) on PRGF6600. The calculation of each is explained in detail, in a Special Topic.

Show Cause & Appeal Parameters:

The Show Cause and Appeal check box settings at the System Level (PRGF2100) control the availability of Show Cause and Appeal at every level. If they are not selected at the System Level, they cannot be selected for either Organisational Unit or Course Version configurations. (All other parameters in the table above can be 'off' at System Level, without blocking the ability to turn them 'on' at either of the other 2 configuration levels.)

Where the system allows a Show Cause and/or Appeal period, these setting can also be overridden at three levels.

For an Organisational Unit using the configuration form PRGF2300.
For a Course Version using the configuration form PRGF2200.
For a Progression Rule outcome using form PRGF5214.

For example, the System configuration allows a period of both Show Cause and Appeal. Course S306 - Bachelor of Engineering is configured to allow an Appeal Period, but not a Show Cause Period. A Progression Rule to evaluate students in this course has 2 outcomes defined. One will place a student on probation; the second will suspend the student. The first outcome is not set to override the Show Cause setting inherited from the Course Version configuration. However it is considered appropriate that students who have the suspension approved be given a period in which to Show Cause, so the Course Version configuration setting is overridden for that outcome, in PRGF5214.

The default settings for the Apply Outcome Before Show Cause/Appeal check boxes follow standard practice and it is recommended that changing these be done only after careful consideration. It is assumed that a student who fails a Progression Rule would be allowed a period in which to Show Cause before any action is taken against him. Therefore the default setting is to not allow the application of an outcome before a student has shown cause or the period available has expired. An appeal is assumed to occur after a penalty has been imposed (and the system default is to allow the application of an outcome before the end of any appeal period).

Show Cause and Appeal Length Values

A value can be set for these parameters in the Progression Calendar overlay of the configuration forms (at the System, Organisational Unit or Course Version level). The numeric value entered represents a number of days and is used to derive the Show Cause and Appeal Expiry Dates applicable to an individual student under the relevant configuration level. (Refer to the Special Topic for a detailed explanation of this derivation.) A user with the required authority can override derived Expiry Dates for an individual student, following their initial derivation.

Where a length is not entered at either the Organisational Unit or Course Version level, values are inherited from another configuration level.

For a Course Version, the Organisational Unit values (if they exist) are used, if not the System-wide values default.
For an Organisational Unit, the System-wide values are used as the default, when no value is entered.

Where a Show Cause or Appeal period is not allowed, no value can be entered against the relevant length field.

Other Specialist Issues

Setup for Existing Student Course Attempts

Existing Student Course Attempts will have a null Progression Status. If a valid status is not established for existing students, one will not be derived until (and unless) the student fails a Progression Rule. Student Course Attempts recorded after the Progression Subsystem has been implemented have their Progression status set to GOODSTAND by default.

Modifying the Progression Structures

Once established, the structures within which the Progression Subsystem functions should only be modified with care. In making any modification to the configuration, Calendars, Academic Encumbrances, Progression Rules or Progression Outcomes, staff must be aware that:

Changes do not apply retrospectively to already existing records (e.g. Person Encumbrances created through the application of Progression Outcomes).
Making modifications to the structures within a Progression Period has important ramifications. Within a single Progression Period students may be evaluated differently because a modification was made. For example, modifying the configuration to allow a Show Cause Period, where there had been none, results in some students within a single period being denied rights granted to others. From a student point-of-view, changes like this result in an inconsistent and discriminatory system. The timing of any modification to the structure must be carefully considered and ensure that students are treated consistently.

Progression Calendar Rollover

Institution policy on Calendar Rollover should be reviewed in relation to Progression Calendars, because of the implications for the Derivation of Progression Outcome and Encumbrance Expiry Dates. Where an institution requires that Progression Outcome Expiry Dates should be derived as soon as the outcome is applied to a Student Course Attempt, the Calendar rollover process must create the required number of future Progression Calendar Instances.

Where these future Calendar Instances do not exist, the Progression Maintenance Process (PRGJ6450) checks for the existence of required Calendar Instances as part of the process to derive Expiry Dates for open-ended Progression Outcomes and Encumbrances.

MDL Views to support Progression

Relevant Meta Data Layer views are listed. This is not a complete list and additional views may be useful to a particular institution. (Refer to Meta Data Layer Overview - this provides an overview and a link to the relevant technical documentation.)

Progression Rules:	Other:
MDL_UNIT_RULE_V	MDL_SCA_ACTIVE_V
MDL_PROGRESSION_RULE_V	MDL_SCA_DISCONTIN_V
MDL_COURSE_TYPE_PRG_RULE_V	MDL_SCA_COMPLETED_V
MDL_ORG_UNIT_PRG_RULE_V	MDL_STUDENT_COURSE_ATTEMPT_V
MDL_CRS_VERSION_PRG_RULE_V	MDL_PERSON_ENCUMBRANCE_V
MDL_STDNT_CRS_PRG_RULE_V	MDL_ENCMB_TYPE_EFFECT_V
MDL_PROGRESSION_RULE_OUTCOME_V	MDL_PERSON_ENCMB_EFFECT_V
MDL_PRG_RULE_CAL_TYPE_V	MDL_SCA_INTERMIT_V
MDL_CRV_CI_RULE_APPL_V
MDL_SCA_CI_RULE_APPL_V

Last Modified on 12 March, 2004