Skip to main content
An admission application is the central record for each applicant in a cycle. It holds the applicant’s personal details, their custom form responses, a snapshot of the form at submission time, all uploaded documents, and the full history of every status change. Applications can arrive from two directions — an applicant fills out the portal themselves, or a staff member creates one on their behalf — and both types move through the same review workflow.

​
Self-apply vs. staff walk-in

TypeHow it’s created
Self-applicationApplicant completes and submits the form on the applicant portal
Walk-in (staff-created)A staff member creates the application on behalf of a walk-in applicant via the admin panel
Walk-in applications are useful when an applicant arrives in person without prior online registration. Staff enter the applicant’s details directly and can immediately move the application through the workflow without waiting for a portal submission.
Every Edurie account represents exactly one person. If an applicant already has an account (from a previous application or another role), staff should link the walk-in application to their existing account rather than creating a new one.

​
Application status lifecycle

Applications move through a linear review pipeline with several terminal outcomes. The table below describes each status, what it means, and who can drive the transition.
StatusMeaningWho can act
draftCreated but not yet submitted. Editable by the applicant or staff.Applicant, Staff
submittedSubmitted and waiting for a reviewer to open it.Staff
under_reviewA staff member has started the review.Staff
acceptedApplicant has been accepted. Eligible for enrollment clearance.Staff
waitlistedApplicant is on the waitlist pending available slots.Staff
rejectedApplicant has been declined. Terminal.Staff
withdrawnApplicant or staff withdrew the application. Terminal.Applicant, Staff
enrolledApplication has been fully converted to a student record. Terminal.System (auto-set on conversion)
expiredAccepted or waitlisted application lapsed without being processed. Terminal.System
draft → submitted → under_review → accepted  → enrolled (terminal)
                                 → waitlisted → accepted (if slot opens)
                                 → rejected   (terminal)
                    ↕
                withdrawn        (terminal)

​
Reviewing and moving an application through statuses

1

Open the application

Navigate to Admissions → Applications. Use the search, status filter, or cycle filter to find the application you want to review. Click the applicant’s name to open the detail view.
2

Start the review

Click Start review. This moves the application from submitted to under_review. Only one reviewer needs to do this — it signals to the rest of the team that someone is actively processing the application.
3

Review documents

Switch to the Documents tab and verify each uploaded file. An application should have all required documents verified before you accept it. See Document Review for the full verification workflow.
4

Check pre-enrollment (optional)

Open the Pre-enrollment tab to view or modify the classes attached to this application. You can add or remove classes before making a final decision. See Pre-enrollment below.
5

Accept, waitlist, or reject

Choose the appropriate outcome from the Actions dropdown: Accept, Waitlist, or Reject.
6

Issue enrollment clearance (accepted only)

After accepting, click Clear for enrollment to issue the registrar’s clearance. This enables the Convert to student action. You can add optional remarks at this step.

​
Assigning a section to an application

A section represents a class group (e.g., “Grade 7 — Einstein” or “BSCS Block A”). Assigning a section during admissions lets you populate class groups before conversion, and automatically attaches the section’s reserved classes to the application’s pre-enrollment list. To assign a section, open the application’s Details tab, click Edit, and select a section from the Section dropdown. The section assignment is carried over when the application is converted to a student.
You can filter the Applications list by section to see all applicants assigned to a particular group — useful for verifying headcount before a term begins.

​
Pre-enrollment: attaching classes before conversion

Pre-enrollment lets you build a student’s class load while they are still an applicant. Each attached class becomes an active class enrollment at the moment of conversion, eliminating a separate scheduling step.

​
Managing pre-enrollment

Open the application’s Pre-enrollment tab to add or remove classes. You can update the list as many times as needed while the application is being reviewed.

​
Pre-enrollment rules

  • Classes must belong to the same academic period as the cycle.
  • Classes can be attached or detached only while the application is under_review or accepted.
  • If a class has a capacity cap and is already full, you will see a validation error. School admins with the appropriate permission can override this limit using the Force Enroll option.
  • Once an application reaches a terminal status (enrolled, rejected, withdrawn, or expired), the pre-enrollment list is locked and can no longer be changed.
Accepting an application when one or more pre-enrolled classes are over capacity will surface a blocking error. Open the Pre-enrollment tab for that application to review and override capacity limits before retrying the accept action.

​
Waitlisting and rejecting applicants

Waitlisting is a non-terminal status. A waitlisted applicant can later be accepted if a slot opens. To promote a waitlisted applicant, use the accept action — the standard review workflow continues from there. Rejecting is terminal. Once rejected, an application cannot be moved to any other status. If you need to reconsider a rejected applicant, they must submit a new application in a new cycle (or contact support to reinstate the application).

​
Identity risk checks

When a staff member views or processes an application, Edurie automatically checks whether the applicant might already exist in the system — matching on email, phone, name, or student number. The result surfaces as a risk level on the application:
LevelMeaning
clearNo existing records match this applicant
warningWeak matches found — review before proceeding
blockedStrong matches found that must be resolved before conversion
A blocked identity risk level prevents conversion. Review the matched records and either link the application to the existing account or confirm the applicant is a distinct person before proceeding.