Introduction to the Quercus Lifecycle Modules<>

Overview of the Quercus Lifecycle modules

Lifecycle modules and services

Quercus Lifecycle modules allow you to create online services. A service provided by a Quercus Lifecycle module has the following characteristics:

it provides a web address where an individual (typically a student) can complete a task such as paying fees or registering for an event

it provides a set of options in the administrative interface which allow administrative staff to view and process requests from students

it allows you to associate a service with a workflow: so that requests can be processed in the correct sequence by the correct staff

it links the requests with existing records in the database — so you can instantly see all the interactions associated with a specific student or a specific event

Users of a service

Applicants and students

Services are used by applicants to the college and by students. Services allow them to perform a variety of tasks, such as looking up information about courses, applying for a course, paying fees or booking seats at a graduation ceremony.

Administrators

Services are used by administrative staff to monitor and process requests and requests from the applicants and students mentioned above.

How does a student access a service?

Students can access the various services in several ways:

through an ‘out-of-the-box’ web portal which is provided as part of all Quecus implementations

through a mobile-optimised version of the web portal

through dynamic links added to your own institution’s portal or to a third-party website

through email or text messages (these may include hyperlinks to web destinations)

These methods are described below.

Quercus portal

What is the Quercus portal?

Quercus has its own student portal. This is a URL where a student can access all his enabled Quercus services. For example, if the a Plan Curriculum service has been set up for the student’s course, a ‘Plan Curriculum’ link will appear when the student logs into the portal.

What links does the student see?

The student sees the range of services relevant to his current phase in the student lifecycle. So, prior to the beginning of the new academic, year the student might see Confirm a Place and Build Curriculum. Towards the end of the student’s final year the Attend Graduation link might appear. Exactly which services appear depend upon which services you have enabled and the access controls you have in place.

What is the address of the portal?

The address of the portal can be mapped to the URL of your choice. You should agree this prior to implementing any Lifecycle modules. The CampusIT help desk will assist you to map the portal to the address of your choice.

Can the portal be customised?

The portal can be customised to fit a college’s own branding requirements. You can change the default colours and display your own logo.

CampusIT portal

Mobile

The Quercus portal is also available in a format which is optimised for mobile devices such as iPhones or tablet PCs. The data which can be accessed is the same as the ‘standard’ portal with the exception of financial information (such as fees paid). Financial information is not made available for security reasons.

The address of the mobile portal can be mapped to the URL of your choice.

Institution’s portal

You can embed dynamic links to Lifecycle module services within your own portal. This allows you to include Lifecycle services as part of a personalised user experience. In practice this means that if a student has logged into your portal she can can see links to the appropriate, enabled services. This facility is supported by the Quercus LiveLink XML feed and its associated API.

Communications

A student may also receive some information in the form of emails or text messages.

During a multi-stage process such as an application, the student (or applicant) may receive automatically-generated emails or text messages which provide progress updates. These communications are specified during the service set-up and are triggered when the application moves from one stage to another in the workflow.

In addition all Lifecycle modules provide communication facilities which allow service administrators to communicate with any or all of the service’s end-users on as as-needed basis.

What pages and fields does the student see?

The web forms and the fields which the student sees are determined by the options chosen when the service is set up. Pages and fields can vary from one course to another if required.

For example the Apply Online could ask the student to attach a CV or this stage could be skipped — depending upon the admissions process for the particular course.

How does an administrative user access the service?

Types of administrative user

There are two types of administrative user:

1a member of the college’s academic or administrative staff who uses the Lifecycle modules to process student interactions

2someone who sets up and administers the services provided by the Lifecycle modules.

We will refer to the first as a staff member, the second as a service administrator.

Access for staff

Staff members can access student interaction data via the Interactions option.

Note: To access this option staff members must be a member of the OAPL_APPLICATION LDAP group.

The services and data which a staff member can access will depend upon which Quercus security model your institution has implemented. For example you can restrict access so that individual academics only see the interactions relating to their ‘own’ courses.

» For more information see:

QuercusPlus Menu 8.0.2 User Guide, Security and access models

New features in Quercus 8.1, Improved security model

Security options and Control Centre access

Access for service administrators

Administrative users can access student interaction data via the Services option.

Note: To access this option the user must be a member of the OAPL_SERVICE_ADMIN LDAP group.

The services which a service administrator can access will depend upon which Quercus security model your institution has implemented. For example you can restrict access so that administrators only see the services relating to their own organisation (see diagram above).

What information does an administrator see?

Staff members

Summary of interactions

When staff members first access a service they see a bar chart which summarises all the interactions received by the service. The chart categories the interactions by their status. So, in the case of Apply Online, there might be bars for ‘Offer Sent’, ‘Offer Accepted’ and ‘Offer Rejected’. The number of bars will depend upon the number of possible statuses in the workflow and whether or not there are any interactions associated with these statuses.

Details of interactions

To get a more detailed view of the interactions you can click on one of the bars of the chart. This will list everyone with an interaction at the status in question. You can now open the individual’s record and review the interaction. For example, if the individual had submitted her choices of modules via the Plan Curriculum service you could see the choices and review them. You can also change the status of the interaction at this point, e.g. from ‘Submitted’ to ‘Approved’.

Student Records

The interactions are presented in the context of a summary of the student’s (or applicant’s) record together with a shortcut link to the student’s complete record. This makes it easy for staff to review any related information which may be relevant to the processing of the interaction

Example: a staff member could click the Communication tab to see any previous communication with the student. Or could click the shortcut to the student’s complete record and then click the Finance tab to see the students’ payment history.

Note: Individual components of the student record can be shown or hidden from particular groups of users. For example, only staff within the Finance Department may be allowed to see the student’s financial information.

Courses and modules

When staff are viewing interactions they can filter the list of interactions so that they show only those relating to a particular course or module. This is useful if staff members have responsibility for processing only the interactions associated with particular courses.

Status

When an interaction is presented to staff members they can see the status of the interaction, for example ‘Offer Sent’, ‘Offer Accepted’ and ‘Offer Rejected’. If a staff member has the correct authorisation he can change the status. When the status of an interaction is changed this usually triggers an associated action of some kind. For example the sending of an email (in the case of ‘Offer Rejected’ it might being ‘We are sorry …’) or the updating of records on the database (in the case of ‘Offer Accepted’ it might trigger the creation of a new student record).

Communication

A staff member can send a text message or email to the individual linked to an interaction at any point during the interaction. These communications are permanently associated with the interaction and are stored in the database.

Service administrators

Services area

To administer a service choose the Services option from the Home page or click the Services button in the top bar.

Note: To access this option the user must be a member of the OAPL_SERVICE_ADMIN LDAP group.

The Services area comprises a number of options which allow the service administrator to configure the online interaction that the student will experience. When setting up a service the you normal proceed through these options in sequence.

Service configuration options

Configuring what students see

A service administrator can configure a range of settings which, together, determine how a service will appear to a student and what information will be collected. For example, the service administrator can decide what screens and fields a student sees when registering with the college through the Confirm Place service. Is just a quick confirmation required from the student? Or will the college take the opportunity to let the students choose which modules they will take? Or update their contact details? Or perhaps fill in a survey? These settings can be configured on a course‑by‑course basis.

» For more information see the Quercus 8.0.2. Control Centre User’s Guide, Creating and using templates.

Configuring how the incoming interactions are processed

In addition, the service administrator can decide how the incoming interactions will be processed by staff members. Should an online application be routed straight to the relevant department? Or should it be screened first by the Admissions Office? Or should the Fees Office perform the first check? The service administrator can set these options through the Workflow section of the administrative area. Workflow is the sequence of administrative events that are triggered when an application is submitted by a user of the online service: each course or course instance can have its own workflow if required.

» For more information see the Quercus 8.0.2. Control Centre User’s Guide, Setting up workflow.

Configuring when services are ‘live’

Finally the service administrator can decide when the service for a particular course should be ‘live’ – that is to say available to students. Service administrators can also stop services.

» For more information see the Quercus 8.0.2. Control Centre User’s Guide, Going live with a service.