| Top of ADM | Index | Table of Contents | Feedback | |
Understanding Admissions
This section of the user manual provides a broad overview of the Admissions Subsystem. A separate section, Admissions - for the Subsystem Specialist, provides more detailed information.
Topics covered include:
Pre-enrolment of Admission Applications is documented in the Enrolments Subsystem
Detailed explanations and instructions for the use of individual database forms can be accessed from the Subsystem's Table of Contents or via the numerous links provided here.
Information regarding Subsystem Reference Data and Setup is provided separately for the Subsystem Specialist.
What the Admissions Subsystem Does
The Admissions Subsystem is used to manage the Admissions processes of the institution. Key functions in this management process are:
Terms Used in the Admissions Subsytem
To understand the Admissions Subsystem it is necessary to understand the following key terms. Explanation of all Admissions terminology is provided in the Subsystem Glossary.
| Admission Category |
A means of grouping like Admission Applications. Admission Categories are institution defined. For example, groupings could include 'Postgraduate HECS Liable Domestic', 'Undergraduate Full-fee Paying Domestic' etc. |
|||
| Admission Process |
Within an institution, an Admission Process is a defined set of steps for the receipt, handling and finalisation of Admission Applications. Within Callista, an Admission Process is a defined set of steps for the recording, management and finalisation of Admission Application records within the System. Different Admission Processes can be defined to meet the needs of different groups of applicants. |
|||
| Admission Process Category |
The Callista term for a grouping under which Admission Applications with like Admission requirements can be subjected to a common Admission Process. |
|||
| Intake Targets |
A means of establishing enrolment targets required by the institution and achieved through course offer quotas. |
|||
| Session Details |
Parameters recorded for an Admission Application data entry session which determine the Admission Process being used. In turn, the Admission Process determines which screens, buttons and fields are presented to the user for the recording of applications. |
|||
| TAC |
A state's Tertiary Admissions Centre. For example, Queensland's Tertiary Admissions Centre is QTAC. |
|||
How the Admissions Subsystem is Used, Including:
Institutions are able to configure parts of the Admissions Subsystem to accommodate their particular methods for managing Admission Processes.
Although there are no clear boundaries, as a guide, 'routine' data entry is limited to recording Direct Admission Applications which may include recording requests for Advanced Standing and recording Admission Enquiries.
The remaining functionality is normally used by Subsystem Specialists or System Administrators to set up and maintain the Subsystem. This functionality includes:
These functions are described below and detailed in the Subsystem Specialist section.
Admissions Reference Data and Setup
For the Admissions Subsystem to function effectively, it is necessary to set up specific reference data and define certain data values. This setup of the Subsystem is detailed in the Subsystem Specialist section. The setup of reference data will not concern the majority of users who will see most reference data as a list of values within a form.
Defining Admissions Processes (procedures)
Callista has the facility to define any number of Admission Processes (Admission Process Categories) allowing separate Admission Processes to be created for groupings of applicants with like Admission Requirements. An Admission Process controls which data entry screens are presented to the user as well as the buttons and other features which appear on those screens when recording or updating a Direct Admission Application.
The Admission Process used when recording Admission Applications, is determined by the session details specified by the user (in the Session Details screen of ADMF3000), for their current direct Admissions Data Entry session. Where an application already recorded for an applicant is selected, the session details default to those previously recorded for the application (i.e. for that application only, the Admission Process used will be determined by session details stored with the application).
The setting up of Admission Processes is described in the Subsystem Specialist section.
An Admission Process Category is defined by an Admission Category and a System Admission Process Type. There are five System Admission Process Types, each of which enables specific functionality in the Admission Process Categories to which it is attached. That functionality is described in the following table.
| System Admission Process Type |
Associated Functionality |
| COURSE |
This is the Admission Process Type used for 'typical' direct Admission Applications. The actual process steps available are institution defined. Unless otherwise stated, Admissions documentation applies directly to this process type. |
| NON-AWARD |
Used for Admission to non-award courses (single subjects). Callista only permits course versions with a Government course type of 50, (NON-AWARD) to be recorded using this process type. Units with their award only indicator set to 'yes' cannot be recorded using this process type. |
| RE-ADMIT |
Used for applications for re-Admission to a previously discontinued course. Can only be used where the Admission Course Code is identical to the discontinued Course Attempt's Course Code (but can be used for different course options). Admission Applications using this process type, once offered, cannot have their Offer Response Status set to REJECTED because their course attempt will have been reinstated (unless the course attempt is again discontinued). Similarly, the Offer Response Status cannot be PENDING, LAPSED or DEFERRAL. Admission Applications under this process type can have specified units recorded against them. Note: default mappings set up under ADMF2M20 do not apply to this System Admission Process Type. |
| SHORT-ADM |
The short Admission Process Type typically identifies an Admission Process Category containing a subset of the process steps used for COURSE. It is used to speed applications through the Admission Process where timelines are tight and a 'full' Admission Process is not required. This is the only process type which can be restricted, within an Admission period, to be only available after a particular date. This date is an instance of the 'short Admission start date alias'. Admission Applications under this process type can have specified units recorded against them. |
| TRANSFER |
Used for the Admission and selection of applicants who are currently, or have previously been, enrolled in a course at the institution. Use of this process type causes the 'Transfer' item to appear in the T-list in ADMF3240. Admission Applications under this process type cannot have specified units recorded against them. Course Transfer Through Admissions provides further information. |
The Admission Enquiry facility is used to record and process the details of an enquiry. Key functions in this facility are:
Enquiries Reference Data and Setup
For the Admission Enquiry facility to function effectively, it is necessary to set up specific reference data and define certain data values. This setup of the facility is detailed in the Subsystem specialist section. The setup of reference data will not concern the majority of users who will see most reference data as a list of values within the form.
Enquiries are recorded for persons contacting the institution with regards to courses offered or seeking information on aspects of studying at a tertiary institution. Enquiries are recorded and modified using the Record Admission Enquiries form (ADMF1200). ADMF1200 also contains buttons that navigate directly to related forms. The information which can be recorded either in this form or the related forms can include:
Only address and person details must be recorded. All information that can be recorded in other forms is optional.
New enquiries are recorded by:
Existing enquiries are modified or added by:
and
form (ADMF1211) to locate the enquirer's record
The processing of Admission Enquiry Packages is described in the Subsystem specialist overview as the running of the process will not concern the majority of users.
Direct Admissions describes those applications for Admission which are made directly to the institution (as opposed to TAC Admissions). Direct Admissions are recorded and modified using the Direct Admission form ADMF3000. ADMF3000 also contains buttons which navigate directly to related forms. The information which can be recorded either in this form or the related forms can include:
The Admission Process specified for the current data entry session determines which buttons and hence which related forms are used for the session. This means that not all of the items in the list above might be available for a particular session. For example, an Admission Process can be created for Non-award Admissions where details of Prior Education are not required. This process would not contain the steps for recording of Prior Educational Details and the corresponding buttons would not appear in ADMF3000.
In addition, the Security Role allocated to the user determines which of the available items the user is able to update.
Registering Applications for Direct Admission
New applications for Direct Admission are recorded by:
Existing applications for Direct Admission are updated by:
Course Transfer Through Admissions
The transfer of students between courses can be effected through either the Admissions or Enrolments Subsystems. Transfers through the Admissions Subsystem are performed where the institution requires the student to apply for entry. Typically, this is either where the student must compete with other applicants for a place, or where the two courses are so dissimilar that the student cannot automatically be assumed to be qualified for the new course.
Transfers through Admissions can only be processed in Admission Process Categories with a System Admission Process Type of TRANSFER.
Special Note: There may be a requirement to transfer from Course A to Course B and then back to Course A. If this happens to units in the same year, the normal procedure can be followed. However, if Course B was in a previous year, and transferring back to Course A is in the present year, the following procedure must be followed. The transfer back to Course A will only work successfully when units or unit sets are inserted AFTER the transfer has been completed.
Acknowledgment of Direct Admission Applications
The Admissions Subsystem can use the Correspondence facility to automatically generate letters to applicants, acknowledging receipt of their application. The availability of this function is determined by the way the Subsystem has been set up by the Subsystem specialist. Refer to the section Admission Letters for a more detailed explanation. Acknowledgement letters are generated and printed either:
Direct Admission Application Outcomes
The result of the institution's assessment of an application for Admission is recorded in ADMF3240 as an Outcome Status. The institution is able to define its own Outcome Statuses (in ADMF02F0) but each must be mapped to a System status. Various validations may be applied (depending on setup of the Subsystem) when an Outcome Status is being recorded against an application. For example, a validation can enforce that the documentation status must be SATISFIED before an Outcome Status of OFFER can be recorded. The available System statuses are:
Direct Admission Application Outcome Letter
The Admissions Subsystem can use the Correspondence facility to automatically generate letters to applicants, advising them of the outcome of their application. The availability of this function is determined by the way the Subsystem has been set up by the Subsystem specialist. Refer to the section Admission Letters for a more detailed explanation. Outcome Letters are generated and printed either:
Tertiary Admission Centre Admissions
The TAC Admissions processing was initally built to specifically handle VTAC processing. TAC processes are described here, although processes for other state TACs are similar (QTAC/TISC/UAC).
As a general rule, institutions are required to set up their own reference data to enable their individual TAC process to complete suceessfully. See Technical Documentation (VTAC/QTAC/TISC/UAC) for further details.
Typically:
Processes (described in the Subsystem Specialist section) are run to load the offer round file into Callista. Applicants are pre-enrolled in the courses in which they have been offered places if the Pre-Enrol check box has been set for the job.
Complying with TAC Academic Result Requisitions
Note: The TAC Academic Results Requisition processing has been built specifically to handle TAC processing.
The TAC provides information regarding the prior education of applicants for Admission, to institutions. The TAC obtains this information by electronically lodging requests for academic results with institutions. This is called the Automated Result Transfer System (ARTS). Callista processes the TAC request and produces a file containing the academic results of those students identified from the request. The file is then uploaded by the TAC. The Subsystem specialist section provides details of the process.
Producing TAC Enrolment Statistics
The process has been built to handle TAC's from different states. Each state institution processing their return file is handled slightly differently than another state.
TAC advises the institution that the 'enrolment statistics request file' is available. This file contains records of those applicants offered places by TAC on the institution's behalf. The job ADMJ4300 is run to produce the requested statistics. The Subsystem Specialist section provides details of the process.
Intake Targets are used to ensure that prescribed targets are met within enrolments of students with particular characteristics. Intake targets are described in the Admission Subsystem specialist overview.
Last Modified on24 August,, 2005