We suggest to use the existing institution because in that way you can take advantage of the academic structure setup elements that are shared with “traditional” education as well as for instance the course catalog / class table data in case you want to link your CE products to “traditional” classes.

Admissions for CE can be managed in different ways, we support having an external system like a CRM, external website of webshop providing us with data about the person and the products they want to buy. This data can be imported using our REST based API or using our excel based File Processing module. Next to these two integration capabilities, we have our own storefront / application form framework that institutions can use to receive applications from people wanting to buy CE products. The storefront would normally be linked to the general website of the institution and is able to accept incoming information about the product(s) the person is interested in. From the storefront, the person is guided to a login page where he/she can create an account – sign in as existing account holder or apply as a guest. From the login page, the application form opens to accept the information about the person. After filling in the required details, including online payment if required, the person submits the application and the administration will take over. The information is transferred to a staging area where search / match takes place after which the information is transferred to the actual transaction component.

We expect a person keeps his emplid as that will enable to easily transfer optained credits from CE to “traditional” enrolments and as well keep data around the person, achievements, finance, etc. aligned. In regards to the actual enrollment in the UG program, we expect the person will apply and enroll as normal and relevant CE credits are transferred as transfer credit towards the students record.

Yes, the Continuing Education module can make use of courses in the Course Catalog, either re-use the existing courses to create CE products and / or use the link between product offering and class to link the actual class activities. New products can be defined as courses in the course catalog first, but that is not necessary as such. Its a choice to define CE products firstly as courses in the course catalog before becoming CE products. CE products have their own catalog(s) in the AIR structures in Program Enrolment which are loosely coupled to the Campus Solutions Course Catalog.

Yes, the student can buy a CE product package that consists of multiple courses (or other types of products). These packages are defined in the CE product catalog, have their own details and price and clearly define what content is part of the package . A package may have a certificate assigned that the student will obtain if he has satisfied the necessary educational content. Progress towards the degree is visible in the Academic Progress Tracker of the student, both for administrators as well as for the student in a self service view.

The CE module does not use the “traditional” enrolment processes and cobols. So, it does NOT create an enrolment request. It also does NOT use the student enrolment record. Enrolments are registered and tracked in the transaction model where we also post and track charges and payments in the student account. The academic progress of the student is tracked in the Academic Progress Tracker page (part of the Program Enrolment module).

Only standard address validation as delivered by Campus Solutions is included when entering addresses for students.

Validations like pre-requisites, schedule conflicts and holds will happen when the student submits the application for the products he purchased. If the payment is done online, we will check before we request payment. Optionally, validations can also be applied when an administrator enters a purchase. In case of web service driven integration and / or import of files, the validations can be applied when the information reaches PeopleSoft and follow-up actions can be defined (inform administrator / reject the incoming request / etc.). Validations are managed using rules that are defined in the Rules Engine.

The CE module does not use the “traditional” admissions, student records and enrolment processes / cobols. So, it does NOT create a program stack, term activation, class enrolment, etc. It also does NOT use the program / plan records nor the student enrolment record. Enrolments are registered and tracked in the transaction model and the Academic Progress Tracker (Program Enrolment).

Tax Receipts can be created as we consider these as BI Publisher reports that are populated using the data we store in the transaction model together with the financial data that is stored in the Student Financials module.

The CE Tax Receipts are created specifically for Continuing Education so these will be separate from the delivered PeopleSoft Tax Receipts. But, the CE Tax Receipts can include information for “traditional” enrolments, creating a combined Tax receipt output.

Transcripts can be created as we consider these as BI Publisher reports that are populated using the data we store in the transaction model together with the academic data that is stored in the Program Enrolment module.

The CE module offers a waitlist functionality for product offerings. You can define the maximum number of attendees for the product offering and indicate a waitlist. As an installation option, logic can be activated so that when places become available, the highest ranked waitlist attendee will be automatically enrolled.

Fees for the CE products are defined at product level and cascaded to product offering level where they can be adjusted for exception scenarios. All fees are defined within the CE module but, we have the ability to use course or class fees if those are already defined for a linked class.

The CE module stores all its financial data (charges, payments, waivers, deposits, etc.) in the Customer Account / Organisation account in Student Financials. the CE data follows exactly the same logic as any quick post transaction. Thus, the normal GL processes that your university uses can be applied for any Continuing Education transaction.

Integration to the LMS is possible, either via the same integration as already in use for “traditional” education and / or via a new to be created integration. Depending on the data model in use for the integration as well as the defined scope, we can plug in to the existing integration or create a bespoke new end point for the integration.

The CE module offers class capacity functionality for product offerings. You can define the maximum number of attendees for the product offering and indicate a waitlist. When students purchase products the class capacity is checked before the online payment and / or when they submit their information. Depending on your own business process we can configure the transaction model to save the seat for someone who has a third party that pays for their enrolment. The enrolment status “conditional” is normally used for this purpose and can be included in the class capacity calculation.