Admissions FastTrack User Guide<>

Worked example: setting up a new admissions process

Setting up an admissions process — getting started

You begin by:

documenting your existing admissions processes ensuring that you capture all the variations including how unusual and rare events are handled

documenting any proposed improved processes — with particular reference to how these will handle the variations in the existing process

Note: admissions systems consist of multiple admissions processes.

When we talk about an admissions process, we mean the set of events associated with the processing of applications for a particular programme or group of programmes.

An admissions system will usually need to handle multiple processes because entry requirements and candidate evaluation criteria vary from programme to programme.

The ingredients of an admissions process

An admissions process scrutinises incoming applications and ensures that the university issues an appropriate response to the applicant.

The process is executed by various agencies and actors:

agencies such as UCAS, UKBA

actors such as applicants, university admin staff, academics and applicants.

Component of a process include:

various stages at which the application is assessed against a particular criteria

rules which specify how the assessment is to be processed and assessed at each stage

actions which are performed at the various stages in order to process the application

decisions which are be made at the end of each assessment stage about what happens next

The information you will need to capture about your existing processes​

When you are documenting your existing processes you will need to capture:

the identities of the various agencies and actors involved in the applications process

the stages through which the application travels

how an application moves from one agency or actor to another

the process which are executed by each agency or actor at each stage — including any rules which are applied and any decisions which are made

in what sequence the processes are executed

how a decision made about an application at a particular point in the process affects the subsequent processing of the application

The information you will need to record about proposed, new processes​

When you are documenting your proposed new processes you will need to identify:

the identities of the various agencies and actors who will be involved in the new applications process

the stages through which the application will travel

how an application will travel from one agency or actor to another

the process which will be executed by each agency or actor

in what sequence the processes will be executed

how a decision made about an application at a particular point in the process will affect the subsequent processing of the application

In addition you will need samples of any documents, such as offer letters, which form part of the process.

Why you need to capture information about existing processes, even if you’re proposing to implement a new process

You will need to ensure that any new process will be able to handle all of your existing admissions scenarios. It’s easy to overlook unsual or infrequent scenarios when implementing a new system — the exercise of documenting your existing process is designed to prevent this.

Collecting information about existing processes

We suggest that you collect information about the existing admissions process on a programme-by-programme or department-by-department basis using a form-based survey. Other methods — such as interviewing faculty or department heads or meeting with the admissions office runs a strong risk of missing all-important edge-cases. For this reason we suggest that the survey includes all programmes or is based upon a wide and fully representative sample population.

Structuring the information about processes after you’ve collected it

You should create a graphical overview of the information in the form of cross-functional flowcharts (better known as swim lane diagrams). You should do this for existing processes and for the proposed new processes.

In the examples shown in this section we have used the following conventions:

start and end points are represented as rectangles with rounded corners

generic processing steps are represented as rectangles

decisions are represented as diamonds

data input/outputs are represented as parallelograms

The example below shows a simple workflow for a direct admission application which is handled jointly by the central admissions office and the faculty admissions department.

In the example shown above:

an application submitted directly to the university is delivered to the central admissions office

here it is subject to a series of initial checks before being passed on to the faculty admissions department

if it has failed any of the initial checks the application by-passes the faculty review-and-offer process and can only be deferred or rejected

if passes the initial checks it moves into the faculty office’s review-and offer process

following the review-and-offer process, the faculty can make an offer to the candidate if it chooses

following the offer (or lack of) there is a final review of the application and the candidate is informed of the decision

Sanity-checking your swim lane diagrams

1Create use-cases for each swim lane diagram. The use-cases should describe the movement of various categories of application through the process and encompass as many ‘what-if’ scenarios as possible.

2Use these use-cases to validate the swim lane diagram. As an imaginative exercise, check that you can move each application descibed by a use-case through the process.

By performing this exercise you will expose any missing logic and ensure that you have captured all the nuances of the process.

If you can’t move an admission through a process you will need to modify your swim lane diagram to accommodate the scenario under consideration.

Example use case

Name

Direct Application from UK School Leaver

Actors

UK school leaver

University admissions office administrator

Faculty admissions office administrator

Triggers

The school leaver has decided to apply for a course at the university

Preconditions

The application has been made directly and the students choices have already been captured by the direct online admissions systems

The application is a standard three-year arts degree with no special requirements other than academic suitability.

Postconditions

The student will be informed of the success or failure of his or her application.

If the application is successful the student will receive an offer of a place (possibly conditional on the achievement of certain grades).

Assumptions

Fee processing and financial assessment is not included in this use-case

Normal Flow

1University admissions office administrator checks that application meets basic admissions criteria for age, criminal convictions and entry requirements for the course (A-levels studied etc)

2If basic checks are OK the university admissions office passes the application through to the faculty office.

3The faculty office reviews the application and decides whether to interview the candidate. Some applications may be rejected at this stage and passed to the final review.

4If a decision is made to interview the candidate an interview slot is scheduled

5An interview letter is sent to the candidate

6The candidate confirms availability for the interview

7The candidate is interviewed

8The faculty creates an assessment report and formulates a recommended offer

9The faculty office performs a final review of the application

10The applicant is informed of the final decision

Successful applicants may confirm acceptance of the offer and move into the next part of the process (not in scope in this workflow)

Alternative Flows

If the candidate does not pass the basic checks there is the option, at the final review stage, to defer the application

There may be occasions at step 3 when the faculty decides to offer places without requiring that the candidate attends an interview

Implementing a specific admissions process in Admissions FastTrack

When you have completed and sanity-checked your swim lane diagrams, you are ready to implement a process in Admissions FastTrack.

In Admissions FastTrack implementing a process involves setting up a workflow template which:

specifies which agencies and actors can perform actions at different points in the workflow

defines and sequences the various stages, rules, decisions and actions

Choosing a process for your first implementation

Review the various processes that you have mapped using your swim lane diagrams and pick a simple example which does not have too many branches or alternative paths.

Listing tasks you need to perform

To implement a process you will need to perform the following tasks:

map swim lanes representing actors to LDAP roles

identify, and name, the stages in the process

understand how decisions route applications from one stage to the next

identify any standard communications (such as offer letters) which will support the process

Mapping swim lanes to LDAP roles

Map the swim lanes which represent the actions of individual actors (such as department heads or lecturers) or internal agencies (such as the Admissions Office) to the various LDAP roles you have set up in Quercus.

Note: some swim lanes may represent the actions of external agencies (such as UCAS or UKBA). These swim lanes cannot be mapped to LDAP groups.

If particular swim lanes do not map to existing roles you can either create an appropriate new LDAP role or map the swim lane to a generic LDAP role.

You will use this mapping to ensure that only individuals of the correct category can perform particular actions.

Identifying and naming the stages in the process

There are various stages in the application processing sequence where the application cannot move forwards until a particular process has been performed. For example, you would not normally interview a final-year school candidate without first confirming the candidate’s age and the subjects they are studying at A-level.

Go through your swim lane diagram and divide the process into stages. A stage will usually encompass the execution of an identifiable step in the application process and will usually terminate with a decision of some kind. For example an age check ‘stage’ might seek information about the age of the candidate. The tasks associated with the stage might include a request for validating evidence, such as a birth certificate, and the process might end with a decision to reject or defer the application or to allow it to move to the next stage in the process.

Note that a stage may include several actions or sub-processes (e.g. email the candidate, validate the birth certificate) but that, collectively, these actions are addressing a single task.

In the swim lane diagrams, stages will cross-cut the swim lanes and may include several processing steps (rectangles). They will often end with a decision (diamond).

When you have identified the stages give them succinct descriptive names, e.g. Criminal Conviction Check, Interview, Offer.

The example below shows stages superimposed upon our original swim lanes diagram:

You will use this information to set up stages in a workflow template.

Understanding how decisions route applications from one stage to the next

A stage will always end with a decision of some kind (e.g. reject application, move to next stage of the application).

Using the information in the swim lane diagram, create a spreadsheet showing all possible routes between stages and the associated decisions. A fragment of such a spreadsheet is shown below.

Decisions

From Stage

Age Check

Check Criminal Convictions

Reject Application

Criminal Conviction Check

Check Entry Requirements

Reject Application

Entry Requirements Check

Handoff to Faculty

Reject Application

Faculty Review

Interview

Make Offer

Reject Application

Interview

Make Offer

Reject Application

To Stage

Criminal Conviction Check

Entry Requirements Check

Faculty Review

Interview

Create Offer

Review Decision

In the example above, the Faculty Review stage is followed by three possible decisions:

Interview

moves the application to the Interview stage

Make Offer

moves the application to the Create Offer stage

Reject Application

moves the application to the Review Decision stage

Notice that the decision is expressed in terms of the next action to be performed.

You will use this information to set up the decision options in a workflow template.

Understanding how a documented process will be transformed into an Admissions FastTrack template

Admissions FastTrack allows you to set up a workflow which follows the structure of your swim lanes diagram. The rest of this section shows how you would set up a workflow which corresponds to our example in the previous section.

Step 1 — set up stages

You first set up the stages of the process.

Following from our example these would be Age Check, Criminal Conviction Check, Entry Requirements Check, Interview, Create Offer, Review Decision, Offer, Deferred and Rejected.

To set up stages

1Go to Services > Admissions > Settings and choose the Workflow option.

A screen opens listing any workflows which have already been set up.

2From the Tasks menu select Configure Stages.

A list of existing stages opens.

3Use the Create New Stage option to add the various stages required to support your workflow.

In the screenshot below the Create Offer stage is being added.

When you have completed this process you will see the various stages you have added in the list of stages. These should correspond to the stages you have identified during your analysis process.

Step 2 — set up a workflow

When you have set up the various stages, you can link them together by specifying which decisions are available for a particular stage and where these decisions lead. You do this by creating a workflow and adding a series of stage rules to it. A stage rule specifies a possible transition between two stages based upon a particular decision.

For example you might create rules which specified:

From the Age Check stage you can make the decision to check whether the candidate has any criminal convictions (decision: ‘Check Criminal Convictions’). Making this decision would take you to the Criminal Conviction Check stage.

From the Age Check stage you can make the decision to reject the application (decision: ‘Reject Application’). Chosing this option takes you to the Review Decision stage.

Both of these rules specify a transition derived from the spreadsheet described in Understanding how decisions route applications from one stage to the next.

The full set of transitions required to put the example workflow into operation is listed below:

From Stage

Decision

To Stage

New

Check Age

Age Check

Age Check

Check Criminal Convictions

Criminal Conviction Check

Age Check

Reject Application

Review Decision

Criminal Conviction Check

Check Entry Requirements

Entry Requirements Check

Criminal Conviction Check

Reject Application

Review Decision

Entry Requirements Check

Handoff to Faculty

Faculty Review

Entry Requirements Check

Reject Application

Review Decision

Faculty Review

Interview Candidate

Interview

Faculty Review

Make Offer

Create Offer

Faculty Review

Reject Application

Review Decision

Interview

Make Offer

Create Offer

Interview

Reject Application

Review Decision

Create Offer

Make Conditional Offer

Review Decision

Create Offer

Make Unconditional Offer

Review Decision

Create Offer

Reject Application

Review Decision

Review Decision

Approve Offer

Offer

Review Decision

Defer Application

Deferred

Review Decision

Reject Application

Rejected

Review Decision

Withdraw Application

Withdrawn

Review Decision

Restart Application Process

New

Setting up these transitions will give us the core of our workflow. Once all the transitions are set up you will be able to move an application through the workflow providing:

you manually perform the validation check or sub-process associated with a stage

you manually select the appropriate decisions after you had performed the check

These transitions will generally appear to the user as radio-button options.

The image above shows how the following transitions from the Faculty Review stage would appear.

From Stage

Decision

To Stage

Faculty Review

Interview Candidate

Interview

Faculty Review

Make Offer

Create Offer

Faculty Review

Reject Application

Review Decision

To set up stage transitions

1Go to Services > Admissions > Settings and choose the Workflow option.

A screen opens listing any workflows which have already been set up.

2You are creating a new workflow so choose the Create Workflow in Tasks panel.

3Give the workflow a name and a description and click Create.

The Edit Workflow screen opens.

3In the Tasks list, choose Add Stage Rule.

The Add Stage Rule form opens.

4Use the form to enter details of the various transitions.

When you have completed a transition clicking Create and Create Another will save your transition and allow you to immediately create another.

Note: we advise that, when first setting up a workflow, you create only the bare work flow transitions — without adding the send email options and actions. You can then check that your workflow sequence is correct. Once you have done this you can add emails and actions.

5After adding the various transitions, the example workflow will look like that the screenshot below.

Note: You can check the transitions associated with a specific stage by using the filter above the list.

Step 3 — check your workflow

Now you have set up your stage transitions you can begin to test your workflow. You can associate the workflow with a course and attempt to process test applications for the course in question.

As part of the testing process it is a good idea to refer to the use cases described in Sanity-checking your swim lane diagrams.

In order to perform this test you will need to associate the workflow with a couse and then process an application for that course.

To associate a workflow with a course

1Go to Services > Admissions > Course Workflows and choose the Edit Course Workflows option.

2Search for a suitable course to which you can apply the workflow. Use the dropdown list in Workflow column to select your workflow. In the example below the Direct Admissions workflow we created in the Setting up workflow, has been applied to the Prehistory and Archaeology course.

3Click Save Changes.

You are now ready to process a test application using the workflow.

When you process the application you will be creating an application and moving it through the steps of the various use cases like the example shown below.

Normal Flow

1University admissions office administrator checks that application meets basic admissions criteria for age, criminal convictions and entry requirements for the course (A-levels studied etc)

2If basic checks are OK the university admissions office passes the application through to the faculty office.

3The faculty office reviews the application and decides whether to interview the candidate. Some applications may be rejected at this stage.

4If a decision is made to interview the candidate an interview slot is scheduled

5An interview letter is sent to the candidate

6The candidate confirms availability for the interview

7The candidate is interviewed

8The faculty creates an assessment report and formulates a recommended offer

9The faculty office performs a final review of the application

10The applicant is informed of the final decision

Alternative Flows

If the candidate does not pass the basic checks there is the option, at the final review stage, to defer the application

There may be occasions at step 3 when the faculty decides to offer places without requiring that the candidate attends an interview

To process an application using the workflow

1On the Home screen, click the Admissions button.

The Admissions FastTrack screen opens on the Applications tab.

2In the Tasks list, click the Create Direct option.

3Complete the direct application using the Progress Wizard.

4Ensure the student is registered on a course which has been associated with your test workflow.

5Click the Create Application button.

The student’s application record opens on the Choices sub-tab.

6Click the Workflow sub-tab.

You can see that the application has moved to the Age Check stage and that you have the option of either checking the applicant‘s criminal convictions or rejecting the application.

You can now begin to follow the use-case and validate whether or not the use-case can be executed using the workflow you have set up.

To validate the example use-case

1The university admissions office’s administrator checks that application meets basic admissions criteria for age, criminal convictions and entry requirements for the course (A-levels studied etc).

Options at Age Check stage

Options at Criminal Conviction Check stage

Options at Entry Requirements Check stage

2If basic checks are OK the university admissions office passes the application through to the faculty office.

3The faculty office reviews the application and decides whether to interview the candidate. Some applications may be rejected at this stage.

Options after Faculty Review stage

4If a decision is made to interview the candidate, an interview slot is scheduled.

5An interview letter is sent to the candidate.

6The candidate confirms availability for the interview.

7The candidate is interviewed.

8The faculty creates an assessment report and formulates a recommended offer.

9The faculty office performs a final review of the application.

10The applicant is informed of the final decision and the application moves to the next stages in the process.

The screen above shows the final stage (Review Decision) in the workflow. Note that the stage name in shown in the green band in the centre of the screen and the movement of the application through the workflow is shown in the Workflow History section in the lower part of the screen.

Step 4 — using actions to define what must happen during workflow steps

The workflow sequence we have created above is really just a computerised checklist. None of the associated actions (such as Check Criminal Convictions or Make Conditional Offer) are, as yet, linked to the workflow. Instead we must make the assumption that these actions are performed ‘elsewhere’ – either as a task in another part of Quercus or as an external administrative action. This means that it would be possible to move an application from one stage to another simply by confirming that a task had been performed irrespective of whether it had actually been performed

It is possible, however, to constrain some parts of the workflow so that an application cannot be moved from one stage to another unless the appropriate action associated with the stage has been executed in Quercus.

Example 1 – cannot move application to interview stage unless interview has been scheduled

If an application is at a the Interview stage you can associate the subsequent stage transition (e.g. from Interview to Create Offer) with a ‘Create Interview’ action. If you do this, an application cannot be moved on to the Create Offer stage unless an interview has been scheduled using Quercus’s interview scheduling mechanism. In these circumstances the system will track whether the interview has actually been scheduled (you need to go to the Interviews tab to do this). The option to move the application on to the next stage will only appear when the interview has been scheduled.

Note: If, as in our example, ‘Make Offer’ is the only transition associated with the Create Interview action then the transition to the Create Offer stage will be made automatically.

Note: the system ‘knows’ that the interview has been scheduled when the decision code associated with the application changes to ‘I’. This code changes automatically when you schedule an interview.

Example 2 – cannot move application to review decision unless offer has been made

If an application is at the offer stage (e.g. the Create Offer stage in our above example) you can associate the stage transition with a ‘Create Conditional Offer’ action. If you do this, an application cannot be moved on to the next stage (Review Decision in the example) until an offer has been created using the Quercus’s Create Decision mechanism (you need to go to the Decision tab to do this). The option to move the application on to the next stage will appear only when the conditional offer has been made.

Note: If, as in our example, ‘Make Conditional Offer’ is the only transition associated with the Create Conditional Offer action then the transition to the Review Decision stage will be made automatically.

Note: the system ‘knows’ that a conditional offer has been made when the decision code associated with the application changes to ‘C’. This code changes automatically when you enter the offer details.

Available actions

The Admissions FastTrack module allows you to associate a stage transition with any one of the predefined actions listed in the table below. These actions may run entirely automatically ‘behind‑the‑scenes’ (e.g. the status change associated with the Confirm Offer action) or they may require input from administration or academic staff (e.g. the need to enter offer details associated with the Create Conditional Offer action).

Description

Function

User input required

Confirm Offer

Changes the decision code to F (Firm Accept) providing the applicant is at an appropriate status (i.e. has received an offer).

None.

Create Conditional Offer

Does not allow you to move the application further in the workflow until a conditional offer has been created.

Movement is permitted when the decision code C (Conditional Offer) has been recorded.

You must create a conditional offer via the Decision tab.

Create Interview

Does not allow you to move the application further in the workflow until an Interview has been scheduled.

Movement is permitted when the decision code I (Interview) has been recorded.

You must schedule an interview by clicking the Interviews tab and then selecting Schedule Interview in the Tasks List.

Create Student

Creates a student record based upon the applicant’s details and choice of course.

The initial student status is set to pre-registered.

Normally this action would be associated with the final step in a workflow.

None.

Create Unconditional Offer

Does not allow you to move the application further in the workflow until an unconditional offer has been created.

Movement is permitted when the decision code U (Unconditional Offer) has been recorded.

You must create an unconditional offer via the Decision tab.

Delete Student

Deletes a student record,

This action can typically be used as an ‘undo’ for the Create Student action. So if you create a transition from (say) an ‘Offer Confimed’ stage to a ‘Student’ stage which is associated with the Create Student action you could also create a ‘Student’ stage to ‘Offer Confimed’ transition associated with the Delete Student action. This would delete the previously created student record and move the applicant back to the ‘Offer Confimed’ stage.

None.

Reject

Changes the decision code to R (Rejection).

None.

Withdraw

Changes the decision code to W (Withdrawal).

None.

Understanding where to use an action

The table below shows the two stage transitions where you may consider using the Create Interview action — going into the Interview stage or coming out of the stage. However, in the case of this action you would use it coming out of the stage as the action ought, logically at least, to take place during the stage: it should not happen before reaching the Interview stage.

From Stage

Decision

To Stage

Action

Faculty Review

Interview Candidate

Interview

Interview

Make Offer

Create Offer

Create Interview

In contrast the Withdraw action is used going into the Withdrawn stage as it is an action that has to happen before the application can move to the Withdrawn stage.

From Stage

Decision

To Stage

Action

Review Decision

Withdraw Application

Withdrawn

Withdraw

To add an action to a processing step

1Go to the Transitions screen and click the Edit button of the transition with which you wish to associate an action.

2The Edit Stage Rule form opens at the foot of the list of transitions.

3Choose the appropriate action from the Execute drop-down list.

4Click Save.

The newly associated action now appears in the Action column.

Step 5 — automate processing steps using rules

There are some parts of the application process which can be automated by taking advantage of special Admission FastTrack processing functions known as rules.

Rules are processing functions which automatically check some aspect of the information in the candidate’s application then perform an appropriate action based upon the result of the check.

For example an ‘Over 18 Check’ function might check (using the information in the applicant’s data-of-birth field) that the applicant will be over 18 at the start of the next academic year (defined by reference to the AGE_IN_YEAR and AGE_IN_MONTH parameters). If the applicant passes the check the applicant is be automatically moved on to the next stage in the workflow without the need for administrator intervention.

Note: rules can only be applied to machine-parsable data fields (such as the candidate’s birthdate). Rules cannot be applied to areas which require the application of human judgement (such as the appropriate offer for a specific candidate).

Note: specific rules can only be used if the incoming application type contains the appropriate data. For example the Criminal Conv. Check function is designed to work in conjunction with an incoming application containing a ‘Criminal Conviction Y/N’ field. If the candidate has answered ‘N’ the function moves the application to the next stage without the need for operator intervention. If, however, the incoming application does not contain this ‘Criminal Conviction Y/N’ field then the function should not be included in the workflow.

Rules available

Description

Function

Course assignment check

Criminal Conv. check

Checks whether the applicant has indicated that he or she has a criminal conviction. If the application has indicated ‘N’ the application moves automatically to the next processing step.

Health/Disability check

Checks whether the applicant has indicated that he or she has a disability or health issues. If the application has indicated ‘N’ the application moves automatically to the next processing step.

Over 16 check

Checks whether the applicant is over 16, 17 or 18 on the dates defined by reference to the AGE_IN_YEAR and AGE_IN_MONTH parameters.

These parameters are set via the Service Menu > Settings > Parameters option:

Over 17 check

Over 18 check

To add a rule to a processing step

1Go to the Transitions screen and click the Edit button of the transition with which you wish to associate the rule.

2The Edit Stage Rule form opens at the foot of the list of transitions.

3Click the Automatic check box then choose the appropriate rule from the drop-down list.

4Click Save.

The newly associated action now appears in the Action column.