Resource

Leaving Well

What happens when a pupil leaves — a clearance checklist instead of a deleted row, a graduate who keeps their login read-only, and a transcript the school can still produce a decade later.

School AdminStudent
Leaving Well

Every pupil leaves. Most systems only handle arriving.

Admission is a process in every school MIS. Departure is usually a dropdown. This walkthrough follows the other half: raising an exit without touching the pupil’s record, clearing what they still owe across fees, library, hostel and school property, and — for graduates — turning a leaver into an alumnus who keeps the same login, read-only, with the school still able to answer an employer’s question years later. Every screen below is the real application, live with sample school data.

Step 1 · School office

Raising an exit changes nothing yet

A departure is a process, not a field. The office raises an exit against a pupil — or a whole graduating cohort at once — and the pupil stays enrolled while it is worked through. Nothing about their record moves until someone completes it.

1

The pupil, still a pupil

Exits start from the student register, because at the moment of departure the subject is still an active student. Their class, their results, their attendance — all of it is live, and all of it survives the exit intact.

A leaver is never deleted; their history is what makes a transcript possible later
The exit surface sits inside Students, which owns the status and the enrolment
Graduation, withdrawal, transfer-out and expulsion are the four terminal exits
Suspension is not an exit — the pupil is still enrolled, so nothing is cleared
2

The exit queue

Every open departure in one place, with what each one is still waiting on. A graduating cohort of two hundred is raised in a single action, and each pupil gets their own clearance checklist underneath.

Raise one pupil or a whole cohort in one pass
Per-pupil failures are reported, never silently skipped
Awaiting clearance, held by clearance, and completed this year at a glance
The queue is the only place an exit is applied — deliberately not the wizard
3

Wizard 1 of 4 — who is leaving

Raising an exit is four decisions, one screen at a time. First: which pupils. The picker searches the whole roll by name or admission number, and takes a single leaver or an entire graduating cohort in the same pass.

Search the roll by name or admission number
One pupil, or a whole cohort selected together
The exit type is chosen here too — graduation, withdrawal, transfer or expulsion
Each type explains its own consequences before you commit to it
Nothing is written until the final step
4

Wizard 2 of 4 — why, and when

The effective date and the reason. The date is what the pupil’s record will say they left on, so it is asked for explicitly rather than defaulted to whenever somebody got round to the paperwork.

An effective date that is the pupil’s actual last day, not the data-entry date
A reason, kept on the exit record permanently
Internal notes for the office, separate from the reason
Required before the wizard will let you continue
5

Wizard 3 of 4 — staying in touch

Only for exits that can become an alumni relationship. A leaver’s school email stops working the day they go, so this is the one chance to capture an address that will still reach them — and the consent to use it.

A personal email and phone, captured while the family is still reachable
An explicit opt-in to future contact — silence is never taken as consent
Guardian consent recorded separately for pupils under age
The step is skipped entirely for exit types that capture no contact, such as expulsion
6

Wizard 4 of 4 — review, then raise

Everything the exit will say, in one place, before anything is written. Raising it creates the record and the clearance checklist — and changes nothing about the pupil. They are still enrolled, still in their class, still on the register.

Every pupil, the type, the date and the reason, on one screen
Raising creates the exit and its checklist — and nothing else
The pupil stays enrolled until someone completes the exit from the queue
Pupils who cannot be raised are reported by name, never dropped silently
Step 2 · School office

What the pupil still owes, from every module

Clearance is the part a spreadsheet cannot do. The checklist is assembled from the modules the school actually runs — outstanding fees, books on loan, a hostel bed, a school laptop — so nobody has to remember to check four systems before a pupil walks out.

1

School property, on the record

A laptop issued to a pupil is tracked against that pupil, so the clearance check can ask a real question. Anything still out appears on their exit; anything returned closes cleanly and the asset is free to issue again.

Issue a tracked asset or a quantity of stock, with an optional return-by date
One asset cannot be out with two pupils at once
Overdue items are flagged, and a lost item can be written off rather than fudged
The issuance history survives the asset being disposed of
2

One pupil’s clearance checklist

Opening a raised exit shows what that pupil still owes, assembled from every module the school runs. Chinaza has two items outstanding and one of them blocks completion — which is the whole question the checklist exists to answer.

One line per source: fees, library, hostel, school property
Cleared, outstanding and waived shown distinctly — not a single tick
Blocking lines called out separately from advisory ones
Each line names who cleared it and when
Completing the exit is the action on this screen, once the checklist allows it
3

Blocking is advisory, and overrides are named

Unpaid fees, unreturned books and an allocated bed are marked blocking. But a school is never trapped: an authorised actor can complete anyway with a reason, and that override is recorded against their name rather than disappearing.

Fees, library, hostel and property blocks are generated only for modules the school runs
A source with nothing outstanding still appears, pre-cleared — silence is not assurance
Waiving a line needs a reason; completing over a block needs an override reason
Clearance can be delegated on its own, without the power to expel
Step 3 · School office

A graduate becomes an alumnus — on purpose

Completing a graduation exit does not hand anyone anything yet. It creates a pending intake, and a person confirms it. That gap is deliberate: a graduation batch can be rolled back, and a rollback must never leave a cohort locked out of accounts they still need.

1

The intake inbox

Graduates arrive here after their exit completes. Confirming is what swaps their student login for a read-only alumni one — the same credentials, but they can no longer submit work or message staff. A school can also confirm without granting any login at all.

Nothing about the pupil’s access changes until a human confirms
Only graduates reach this inbox; withdrawals and transfers do not become alumni
A pupil who never had a login is still a perfectly valid alumnus
Confirming is a distinct permission from reading the registry
2

The alumni registry

Former students as first-class records, searchable by cohort, outcome, institution and contact consent — because outcome lives in a real column, not a note nobody can query.

Filter by year group, what they went on to do, and whether they can be contacted
Contact details are encrypted at rest; the fields the registry filters on are not
Export what is on screen, not everything, so a filtered view exports what it shows
Alumni relations can be delegated without granting student-record access
3

One alumna’s record, in full

Opening a record shows the whole arc: who they were as a pupil, what they left with, where they went, and whether the school may contact them. Adaeze graduated in 2024 and is now at the University of Lagos — and she has opted in, so she is reachable.

Their admission number, last class and graduation date, carried over from the exit
Outcome and destination as queryable fields, not a free-text note
Contact details, encrypted at rest and shown only to staff who may see them
Whether they hold a portal login — an alumnus can be confirmed without one
Their exit record is one click away, so the departure and the alumnus stay joined up
4

Cohorts, and what they became

Year groups with their outcome mix — how many went to university, into work, into training. The question a governors’ meeting actually asks, answerable without a spreadsheet.

Every cohort with its size, its contactable share, and who holds portal access
Outcome breakdown per year group
Built from the same indexed columns the registry filters on
Step 4 · School office

Reunions, and the letter an employer asks for

An alumni list nobody uses is a spreadsheet with extra steps. Events and verification requests are the two things schools actually do with their leavers — and both respect the consent captured on the way out.

1

Events that only reach people who agreed to be reached

An event names its audience as a rule — everyone, named cohorts, or particular outcomes — and turns it into invitations when it is published. Alumni who did not consent to contact are skipped, and the school is told how many, rather than quietly reaching fewer people than it expected.

Draft first: nobody is contacted until the event is published
The audience is a rule, so someone confirmed after drafting is still reachable
Publishing reports how many were skipped for want of consent
Capacity counts guests, and the audience cannot be changed once invitations are out
2

Transcripts and verification

The phone call a school office takes years after a pupil leaves: an employer or a university wants confirmation. The request arrives as a record, and the transcript is rendered through the school’s own document template — published marks only, never a teacher’s draft.

The alumnus says what the document is for and who it is going to
Transcripts assemble published results and an attendance summary
Draft marks are excluded — they are working notes, not a record for a third party
Rendered through the school’s Document Templates styling, and stored
A school with no template configured can still record the request as fulfilled
Step 5 · Alumnus

The same portal they had as a pupil

A graduate does not get a new account, a new password or a new app. They keep the login they have had for years — and everything they could once write becomes read-only, except the one place they legitimately act.

1

Their record, their details, their invitations

Results and attendance stay readable for as long as the school keeps them. What is new is a place to tell the school where they went, whether they still want to hear from it, and to ask for the paperwork they need — plus the invitations they have been sent.

Results, attendance and documents become read-only; messaging and assignments go entirely
The alumni module is the one surface they can still write to
Withdrawing consent removes them from every audience, immediately
RSVP to invitations, and request a transcript without phoning the office
A login unused for two years is deactivated — the record and the transcript are not

Run your whole school on one connected platform

Start with the base package, switch on the modules you need, and give every parent, student and staff member a single place to log in.