Admissions - for the Subsystem Specialist

An introduction to, and an overview of, the day to day operation of the subsystem is provided in Understanding Admissions.

Information regarding the use of a specific form is obtained by selecting a link to that form in the text below or selecting from the subsystem table of contents.

• setting up the Admissions subsystem
• setting up admissions reference data
• setting up admission process categories and their steps
• setting up security role access to admission steps
• linking course offering options to admission categories
• configuring admission calendars
• admission calendar rollover
• changing admission dates
• Admissions subsystem processes
• TAC admission processes
• TAC academic results requisition
• TAC request for enrolment statistics
• producing admission enquiry packages
• Defining admission correspondence
• Letter phrases
• Letter parameters
• Letter Rules
• System Letters
• Admission Letter Templates
• linking correspondence to admission process categories
• production of acknowledgment letters
• production of an outcome letter
• producing admission letters via a batch process.
• Maintaining student intake targets
• Derivation of an applicant's Expected Completion Period & Year

Setting Up the Admissions Subsystem

• Create the required reference data for the functionality being implemented
• Having defined the required admission categories and mapped appropriate Enrolment, Fee and Correspondence Categories to them, create admission process categories and their steps
• Where required, refine security role access to admission steps
• Link the course offering options to the category or categories to which they are available
• Configure Admission Calendars (This may have been done as part of the System wide calendar setup)

Setting Up Admissions Reference Data

Setting Up Admission Process Categories and Their Steps

Recorded in the System is the set of all steps identified as belonging to any type of admission process. These steps are grouped according to the type of admissions information involved. When an admission process category is created, the steps for that procedure are allocated to it from the set of all System defined steps. The procedure can be further refined by adjusting the order in which the steps are displayed to System users.

Setting up an admission process category and its steps is done in ADMF2M30 and involves:

• selecting the admission category for which the procedure is being defined
• assigning a System admission process type to the category, creating an admission process category (System admission process types are detailed in Understanding Admissions)
• assigning the steps for that procedure to the admission process category

Detailed explanations are provided for the Maintain Admission Process Category Detail form (ADMF2M30). A list of all admission steps and information about each is also provided.

Setting Up Security Role Access to Admission Steps

Earlier paragraphs describe how the Direct Admissions (ADMF3000) and Maintain Admission Course Application (ADMF3240) forms are dynamically configured to display only the navigation buttons and T-list items specified for the admission process category in use at the time, with each navigation button and T-list item representing a step in the process. The ability of individual users to access the forms, screens and T-list items invoked by these navigation buttons is controlled by the security roles and person privileges granted to the individuals.

An additional layer of security is applied to T-list items. Users with access to a T-list item by way of a security role or person grant are initially only able to view the T-list item data. The ability to update T-list item data is granted via the Maintain System Admission Step Access form (ADMF02O0). The form is used to grant update access for T-list admission steps, to security roles. Only those users with a security role with the appropriate form grants and step access grants can update T-list items.

Callista provides 'intelligent' display of T-list items so that T-list items are only displayed when they are required. For example, the Conditional Offer T-list tab is only displayed when a conditional offer has been made. This is determined by the application having a 'system admission outcome status' of COND-OFFER. A list of the conditions under which T-list items are displayed is provided.

Linking Course Offering Options to Admission Categories

The course offering options potentially able to be offered (see Configuring Admission Calendars, below, regarding restrictions imposed on potential offerings) in an admission period are determined by the admission categories associated with the admission period and the course offering options linked to those admission categories. This linking is performed in CRSF1320.

Configuring Admission Calendars

The Admissions subsystem relies on pre-defined admission periods and key dates for its operation. It is recommended that admission calendars be established for an academic year and then the Calendar Rollover process be used to create framework admission calendars for future academic periods. These can then be modified as required.

• Use CALF0220 to set up calendar instances representing admission periods (calendar category = ADMISSION). Each admission period within an academic period should have a unique name (Calendar Type). It is recommended that each admission period's start and end dates roughly correspond to the enrolment period to which it applies. This may not always be achievable where more than one admission period (for different cohorts of students) relate to a single enrolment period.
• Use the Calendar Relationships button to navigate to CALF0330.
• In CALF0330, link each admission period to both its superior academic and teaching periods. This linking is used in ADMF3250 to determine teaching periods and hence unit offerings relevant to a particular commencement period. For example, a mid year admission period is relevant to units offered in semester 2 but not to units offered in semester 1 or year long. Link each admission period to its subordinate enrolment period. This linking is used by the pre-enrolment process to determine the enrolment period in which applications belonging to a particular admission period should be enrolled. This means that an admission period can have only one subordinate enrolment period.
• In CALF0420, create institution defined date aliases to represent the critical dates listed in ADMF02R0 - one only for each critical date. (use a date alias category of ADMISSIONS or similar and a calendar category of ADMISSION)
• Record the names of the admission date aliases created in the previous step against the critical dates in ADMF02R0. (Each date critical to the operation of the subsystem is listed here)
• Return to CALF0220, locate the previously created admission periods and use the Date Alias Instances button to navigate to CALF0512.
• Using CALF0512, create the required instances of each of the admission date aliases for each admission period.
• Configuration of particular admission periods is continued using the Maintain Admission Period Calendars form (ADMF2M61) as described immediately below.

The kinds of admissions which are valid in particular admission periods are controlled (restricted) by the configurations recorded in the Maintain Admission Period Calendars form (ADMF2M61). In this form:

• the categories of admission applications which are allowed in an admission period are recorded.
• the process types available to each 'admission period-admission category are recorded'.
• for each 'admission period-admission category-process type' combination, the course offering patterns on offer can be restricted to offerings at particular locations and/or particular attendance modes and/or attendance types. An example is where a mid year intake of students is restricted to offerings of a course at a particular campus. (Note: The course offering options potentially available to an 'admission period-admission category-process type' combination are those linked to the admission category in CRSF1320.)

Admission Calendar Rollover

Admission calendars are rolled over using the Calendar Rollover process. This process does not roll over the admission period category/process/course offering restriction details attached to admission periods (in ADMF2M61). To rollover admission period details:

• the Calendar Rollover process must first have been performed in order that the new admission period instances exist, also enabling the System to identify the source instances when performing the Admission Calendar Rollover process. The usual situation would be to roll forward the academic year calendar and all its associated calendars and date alias instances, which includes admission calendars. The dates defining each calendar instance are checked in the Rollover Calendar report (CALR0320) and adjusted where necessary, as are related date alias instances.
• the Course Structure Rollover process must first have been performed in order that rolled over 'admission period course offering option restrictions' can be created to the new course offering options.
• a query is executed in ADMF2M61 to locate each new admission period.
• as a relevant admission period is displayed, the Admission Period Rollover button is selected. The System recognises which admission period the displayed period was rolled from and rolls admission category, process type and course offering option restriction information from the source period to the new period. Where all admission periods for an academic period are to be rolled over, the Admission Period Rollover (Batch) process (ADMJ2M63) should be used. This process rolls over all admission periods for an academic period.
• check the Admission Calendar Rollover Report (ADMR1060) if any warnings were encountered during the Admissions Rollover process.
• any required amendments to the rolled over data are made in ADMF2M61.

Note: Calendars can be rolled as far into the future as required i.e. the 1999 calendar structure must be rolled into 2000 to be able to rollover the 1999 admission period details. However it could also be rolled into 2001 and 2002 and so on if the institution carries out its planning well in advance. To operate effectively, the admission deferment process requires that calendars be rolled far enough into the future to enable the recording of the admission period, admission category and admission process type which will apply to the deferred course application, when the deferment period ends. Otherwise the user will not have an admission period to defer the applicant to. Another solution is to limit deferment to periods of 12 months, renewable.

Varying Admission Related Dates for Particular Admission Period Admission Categories

This function allows the dates set up for an admission period category to be adjusted without 'losing' the original dates. A typical use is the extension of an admission application closing date where the extension only applies to particular locations, attendance modes or attendance types. This date variation function is carried out using the Maintain Admission Period Date Overrides form (ADMF2M62).

The ability to vary a date only applies to the System date aliases (see ADMF02R0):

• Due Date Alias
• Final Date Alias
• Offer Response Date Alias

• The Calendar Rollover process has created a new admission period with a 'course application closing date' of 1 October 1998. The institution determines that whilst this date is correct for most courses, on this occasion 'off-campus' applications for a particular admission category should close later than other courses, on 20 October. The new closing date is recorded for off-campus mode only in ADMF2M62.
• When recording an application for admission in ADMF3240, the Direct Admission process checks the options entered for each course application. When the System encounters an application for on-campus study, it checks for any on-campus override matches. None exist, so the application closing date is 1 October. When the System encounters an application for off-campus study and checks for off-campus override matches, it finds a match (provided that no other attributes which would exclude this application were defined for the override record) and the closing date for that application is 20 October.

TAC Admission Processes

Tertiary Admission Centre Admissions

A broad outline of the TAC admission process is provided in Understanding Admissions.

• The job ADMJ4200 (ADMJ4210 for Postgraduate Offer File) is run through job scheduler. This process:
• invokes a parameter form where the location (directory/file path) of the VTAC 'offer round' file is recorded.
• 'gets' the offer round file and either creates a new person record for each new (to Callista) applicant or locates the record of existing (in Callista) applicants.
• loads personal (where applicable) and admission related data for each applicant to the Admissions subsystem. Admissions subsystem functionality is then applied in a similar manner to Direct Admission processing.

TAC Academic Results Requisitions

 Current or previously enrolled students may apply for admission to other tertiary institutions. To complete their admission application, the prospective institution requires information on the students' results at their prior institutions. The results requisition process allows for the electronic transfer of these to TAC for distribution to the institutions to which the students are applying. This process includes the requisition of Honours level records as well as undergraduate records.

• Initial setup by the System or Database Administrator. A variable , 'TAC', is set up in the Job Control table. It contains the path to the directory in which the TAC data files are located.
• TAC sends an electronic request for academic results which is located by the job in the process below. This is a list of students for whom the results are required.
• TAC may also send a result acknowledgement file, which should be placed in the 'TAC' directory. This contains information on the outcome of validations performed on a previously sent result file. If errors are detected in this file by the process (ADMJ4100), then the process will write a message to the job scheduler run log and will not process any more request files until the result acknowledgement file is removed. The result acknowledgement file will need to be checked manually to see what the errors are and how they are to be resolved.
• The TAC Automated Result Transfer System Extract Process (ADMJ4100) is run through job scheduler. The process looks in the 'TAC' directory for a '.req' file (the request for results). It then:
• verifies the format of the file and writes problems to error records in the request acknowledgement file. If no problems are found then only a header record is written to the request acknowledgement file.
• attempts to match each TAC record against a Callista record
• obtains the student results for each match (student course and unit attempt results) and writes them and any unmatched records to a results file
• the results file is filed in the 'TAC' directory for later access by TAC.

 Producing TAC Enrolment Statistics

• Initial setup by the System or Database Administrator. Two directories, namely TMP and OUTPUT are environment variables which should have been specified in s_job_control. Refer to Technical Documentation for further information regarding environment variables.
• VTAC advises the institution that the 'enrolment statistics request file' is available. This file contains records of those applicants offered places by VTAC on the institution's behalf.
• The request file is copied to the TMP directory.
• The process ADMJ4300 produces statistics of the applicants offered places by VTAC who have subsequently been enrolled by the institution.

The process ADMJ4300 is run through job scheduler. It:

Other Admission Processes

Producing admission enquiry packages

• to run the job Process Admission Enquiries (ADMJ1320) through job scheduler. (This process would normally be scheduled as a standing request to run nightly). This process
• updates the status of REGISTERED or ACKNOWLEDGED enquiries or BOTH
• updates the Last Processed date and sets the Mailed date for all items that can be mailed
• creates a person ID group of all enquiries processed
• run the Enquiry Status Report (ADMR1340) which produces a list of items to be mailed to each person in the ID group
• run the Person Address Labels report (IDGR2100), which produces an address label for each person in the ID group.

Defining admission correspondence

The Admissions subsystem relies on pre-defined correspondence types of OUTCOME-LT and ACKNOW-LET for communicating to students about their current applications. It is recommended that at least one outcome and acknowledgment letter is created and assigned to the admission process categories in use by the institution. A typical setup would follow the following process. Refer to the Correspondence subsystem for further information.

• Letter phrases

Institutions are able to define all common phrases that will be available to the admissions user. These phrases are generally used to communicate to the student specific details that apply to the application. For example, an institution may wish to communicate to a student the documentation that is required to be presented before an application can be considered. These letter phrases are maintained using the Maintain Letter Phrase Form (CORF2550).

• Letter parameters

Institutions are able to define the data that will appear in an acknowledgement or outcome letter. By mapping letter parameter names to system letter parameter types, institutions can determine what information is to be made available for admissions correspondence. These letter parameters are maintained using the Maintain Letter Parameters Form (CORF2510) and rely on Admissions letter parameters, for the system letter parameter type definitions.

• Letter Rules

Institutions are able to define text that will appear in an acknowledgement or outcome letter dependent upon a number of statuses passed from Callista to the rules engine. By mapping letter parameters to parameters of type ADM_RUL.htm#, institutions can determine the exact nature of text that will appear and its location within a template. Admission correspondence rules are maintained using the Maintain Group Rules Form (RULF2001) and rely on Admission Correspondence Rules, for the standard set of rules.

• System Letters

Instititions are able to define mulitple system letters for the correspondence types OUTCOME-LT and ACKNOW-LET. System letters contain the letter parameters and word template filename that will be used to create a letter. System letters for admission correspondence must be mapped to Admission Process Categories, to take effect. System letters are maintained using the System Letter Form (CORF2520).

• Admission Letter Templates

Admission Letter templates are designed using Microsoft Word, and generally contain all the letter parameters that have been assigned to a system letter. Admission letter templates must be stored in the template directory specified in control.doc. The file 'control.doc' (supplied with Callista) is required to be stored in the c:\tmp directory of each client machine from which letters are produced.

• Linking System Letters to Admission Process Categories

System letters, defined for the correspondence types OUTCOME-LT and ACKNOW-LET must be mapped to admission process categories. It is advisable to ensure that the admission process category steps include the step type ADDRESS as a mandatory step. Applicants without a valid postal address, will not receive admissions correspondence. System letters are mapped to Admission Process Categories using the Admission Process Category System Letters Form (ADMF2M34)

• Production of acknowledgment letters

Acknowledgment letter entries can be created for an individual application from the Direct Admission Course Form (ADMF3240). Acknowledgment letters will only be created if the appropriate step type has been included for the admission process category.

Select the Acknowledgment letter button.

Select the Letter button. This will navigate to ADMF3900

Assign the parameter codes to letter parameters for the acknowledgment letter.

Select the Produce Letter button. This will invoke Microsoft Word and merge the appropriate data into the template. The file is automatically saved in the c:\tmp directory with the correspondence reference number. To include this letter in a batch process, select the Reject Letter button.

• Production of an outcome letter

Outcome letter entries are created for an individual application when the outcome status for the application is changed from PENDING to any other status, in the Direct Admission Course Form (ADMF3240). Outcome letters will only be created if the appropriate step type has been included for the admission process category.

Change an application outcome status from PENDING. Save the record.

Select the Letter button. This will navigate to ADMF3900

Assign the parameter codes to letter parameters for the outcome letter.

Select the Produce Letter button. This will invoke Microsoft Word and merge the appropriate data into the template. The file is automatically saved in the c:\tmp directory with the correspondence reference number. To include this letter in a batch process, select the Reject Letter button.

• Producing admission letters via a batch process.

Acknowledgment and Outcome letters that haven't been produced by the Produce Letter button in ADMF3900, and are composed (as indicated in ADMF3900), can be created using two processes. The first process is via the Produce Letters Batch Job (ADMJ5300). This job will create a log file containing the data from Callista to be used in the production of letters. This log file can be used to create all letters of type ACKNOW-LET or OUTCOME-LT, for particular outcome statuses. To produce the letters, the Batch Letter Production form (CORF2540) is used.

Student Intake Targets

ensure reference data is recorded in the Maintain Student Target Type form (ADMF2M41)

in the Maintain Submission Intake Targets form (ADMF2M42), record submission period targets. Each year intake targets are reported to DEST for the submission period

intake targets can be further defined in the Maintain Organisational Unit Intake Targets form (ADMF2M44). Intake targets are broken down for organisational unit and funding sources. Within these combination, targets can be defined for course type group, unit internal course level and attendance mode

using the Maintain Course Student Targets form (ADMF2M45), allows the intake targets to be further defined for each course and associated unit set as required.

Derivation of Expected Completion Period / Year

How are the Expected Completion Year/Period values derived in the Admissions subsystem?

• An Expected Completion Date is calculated using the formula:
  = Course Start Date Alias Instance + Std FT/Std PT Cmpltn Time
  
  (The full or part-time completion time value selected is based on the attendance type for this admission application. The Expected Completion Date can be displayed on ADMF3240 by setting the Display Derived Completion Date indicator)
• Convert Expected Completion Date to the academic year in which the course starts.
• Find the closest 'Completion' date alias instance that is <= Converted Expected Completion Date
• This determines the completion period (SUM, MID, END)
• Calculate the completion year
  = Academic Year of 'Completion' Date Alias + Course Completion Time

Example:

Resulting derived values: