Intakes: What are they and how do they work?

In this page we will explain:

• Intake Mapping
• Creating intakes Before they are opened
• Opening Intakes
• Triggers conditions and “not triggered”
• Closing Intakes
• Grouped Intakes
• Intake Changes

Overview:

In brief, Intakes are how your students are grouped on the CAS shield homepage. Intakes are the highest level students are grouped at, set up to ensure your students are created correctly in CAS Shield and are visible to university users, agents, and students, in the right place at the right time. Intakes in CAS Shield are named for an individual month, but can include students on courses starting on a range of dates (see Grouped Intakes below).

(intakes are selected from the drop down menu on the CAS Shield homepage)

To do this, we configure an “intake ID map”. These are critical to ensure:

• Students are always linked to a valid intake in the platform.
• No students are created in an incorrect or non-existent intake, or without an intake linked to their application.
• Students starting at different months within the same academic cycle are correctly grouped together in the CAS Shield homepage (see Grouped intakes).

Intake ID Mapping:

The intake ID field is mandatory in the system. And the expected intake format is YYYY-MM, for example:

• 2026-09
• 2026-01
• 2026-04

It is very important that this field is correct, because If a student is integrated with an incorrect intake ID, the student will not be created or updated.

In addition, the system does not allow students to be created in Intakes that have not yet been created or have not yet been configured in the platform, or if an Incorrect or unexpected intake ID structure is used (such as MM-YYYY or YY-MM). This ensures that your students are only imported when the system is ready for them, after you have confirmed any and all configuration specifications for that intake, protecting your students data integrity, and avoiding students appearing in the wrong intake or an intake that is not yet visible.

This means that if a university starts sending offers for a future intake, but that intake has not been created or mapped, those students will not be created in the system. Because of this we create intakes before they are opened.

Creating intakes before they are opened:

For many universities, we create intakes in advance. This step happens behind the scenes, with students created in the database and held in an invisible “Waiting for intake” tab. This ensures the team at Enroly can manage and triage integration seamlessly, while you and your students do not get overwhelmed with future applications before you have opened the intake to students.

This is mostly used for universities using API and SITS Turnkey integration, where students are imported automatically when/if they meet relevant triggers, as this allows them to import without any error, even if the intake has not yet opened in CAS Shield. Other integrations may not require early intake creation, but you may want to create intakes early for peace of mind or to troubleshoot integration.

When an intake is created before it has been opened:

• Students' records are created in the database.
• The intake is visible to you on the CAS shield homepage but,
• Students are not visible to university staff.
• Students are visible to Enroly staff, under “Waiting for intake”.
• Students can not access their records in CAS Shield for this intake

Students held in “waiting for intake” will follow the procedure for all students once the intake opens.

An intake is opened at a predetermined date, or at your request, prior to the intake date. When an intake is opened, the system checks if there is a trigger condition configured and if so, checks if each student meets the condition? (see below for an more information and examples of trigger conditions)

If no trigger condition is set:

• All students in the intake move into the CAS process, and will appear under the relevant stages (pre-deposit, post deposit etc) for the intake.

If there is a trigger condition set:

• Students who do meet the conditions move into the CAS process, and will appear under the relevant stage for the intake.
• Students who do not meet the condition are held in the “Not Triggered“ stage.
• These students remain created in the background, but will not be visible in the intake to you university users or the students.
• Once these students meet the conditions they will then appear under the relevant stage for the intake and accessible to all.

Trigger Conditions:

You may want to ensure only certain students are imported into CAS Shield, such as students at a veteran offer statuses

To do this, trigger conditions can be set up to ensure only students you deem ready to view their records are visible in CAS shield, and will only be contacted by us once this trigger has been met.

For example: if you only want to invite students who have accepted their offer, all student records will be created in the background, but only those with accepted offers will appear in CAS Shield, and those who have not accepted their offers will remain not triggered.

Trigger conditions apply to all applicants in the same intake, but can be changed for each intake. If changed after an intake is opened, it will be applied to all students, and those affected will move those from Not Triggered into the process if they meet the new trigger, but students already moved under the old trigger will will remain active at their current stage (as students cannot be moved back into not triggered)

Not Triggered:

“Not Triggered” is a holding stage for applicants that have not met your specified trigger condition. It applies after an intake is opened for all students who belong to an open intake but do not meet the configured intake trigger conditions and are therefore not yet moved into the CAS process.

These students are not visible to university users, and are only visible to Enroly admin under an additional intake tab called Not Triggered, this enables us to find students before they are triggered should you require any support for the intake.

Closing Intakes:

Closing an intake is completed by Enroly staff, at routine intervals, or upon your request.

After you have elected to close an intake, students:

• can no longer access offers linked to that intake and will see a “No active intake” message when logging into the platform, unless they hold a second offer for a different (open) intake.
• cannot upload documents, amend personal details or access CAS Shield for the closed intake.

After you have elected to close an intake, university staff:

• Cannot add new offers or update offer data, and any data received through integration for this intake will be ignored.
• No additional offers can be created for this intake.

After you have elected to close an intake, agents:

• Cannot add , edit or upload any details to a student's records.

Once an intake is closed, you will still have visibility and be able access to all records on CAS Shield for the closed intake, and the students details will also appear when searching in Config.

Grouped Intakes:

Most universities operate with a small number of “main” intakes, for example:

• September
• January
• April

However, students may start throughout the year, like PhD or pre-sessional students, and specific course start dates may run earlier or later than the month the intake is named for.

For Example: if a university has a September 2026 intake, but the exact course start dates may be across September, with some starting in early October (2026-10) and some PhD students starting in October (2026-10) or November (2026-11). If we do not group all relevant months to a main intake:

• Students with start months 10 or 11 will not match any configured intake

• Their intake ID will be cleared

• they will not be created in the system

By default we group all months of the year under the relevant main intakes as below, however this grouping can be configured to best suit your institution's academic calendar.

This ensures students starting at any point in the academic cycle are linked to a valid intake and remain visible in the platform.

Furthermore, by grouping months of a year to defined main intakes:

• We ensure every possible start month is accounted for, without configuring every month as a separate intake.
• We maintain clean data integrity across different integrations.
• We minimise the risk of duplicating student records.

It is important that Intake planning must be confirmed before the intake goes live, as intake changes after data has been sent can cause duplication.

Because of this, if you want to add a new intake, split an existing intake, or change month groupings, this should be done ahead of time as we will need to assess whether students have already been created under the previous configuration to avoid data duplication.

For example: if a university has the April intake grouping courses starting in 2026-04 and 2026-05, but they later want to create two separate intakes for April and May, when the mapping is updated, Students with 2026-05 are now re-mapped to the new May intake, but would also have a preexisting record in the April intake (as this previously groped 2026-05 and 2026-04 together). This results in duplicate student records across two intakes.

When duplicate student records occur due to intake mapping changes, the only two options to rectify this is for either:

• manually move students in the previous intake to closed lost status in the prior intake.
• deleting the affected records before activating the new intake mapping.

Both of these solutions can be time consuming, and may lead to confusion for the student or agents as records are changed/deleted without an apparent cause to those outside of decision making. For this reason we may prompt you to configure intakes before they open, to ensure clarity and confidence that the configuration is right for you and your students.