Student services: requests from students and families
A transcript copy, a class change, transport, financial aid, accessibility: the request becomes an ordinary ticket in the support desk you already have, tagged with an educational category and pointed at the student, the enrolment or the application. Nothing about deadlines is stored by the Education module. Part of the Education vertical, optional and off until an admin turns it on.
The Education screen gains the Student services block. It is where a request from a student or a family gets recorded: a transcript copy, a class change, transport, meals, financial aid, accessibility, a conduct concern. Each one becomes a ticket in the support desk the system already has, with an educational category on it and a link saying who it is about.
It is your support desk, not a second one
This is the whole point of the feature. The request opens as an ordinary ticket: it lands in the same queue, it is measured by the SLA policy you already configured, it respects your business hours and holidays, it is answered in the same console, it carries the same replies, attachments, macros, satisfaction survey and knowledge base. The Education module stores no status, no priority, no queue and no deadline of its own.
That is not a shortcut, it is the safe design. A second deadline clock would mean two answers to the question "when is this due?", and a deadline with two sources is a deadline with none. Whatever the school changes in Settings, under Support, applies to student requests the same day, with nothing to reconfigure here.
The categories belong to the school
The first time you open the block, a starting set of categories is created for you: records and transcripts, enrolment change, tuition and billing, financial aid, admissions, academic support, attendance, transport, meals, health, accessibility, conduct, technology, transfer and withdrawal. Rename them, deactivate the ones you do not use, and create your own.
Each category decides three things about the ticket it opens: the priority, the queue and the ticket category. Those are exactly the three filters your SLA policies match on, which is how an existing policy such as "critical: four hours" starts covering a health request without anyone touching it. A category that is not in your set is refused when a request is opened, so the list on screen is always the list that is really in use.
A category already used by requests is not deleted, it is deactivated. Deleting it would leave the history pointing at a name that no longer means anything.
Every request says who it is about
A request has to point at something: the student, the enrolment or the application. When more than one is filled in, the most specific one names the request, in that order, and all of them stay recorded. You can also record who asked, when it was not the student: a parent, a guardian, the front office.
A request pointing at nobody is refused, and on purpose: that is an ordinary ticket, and ordinary tickets already exist without needing anything from the Education module.
Unclassifying is not deleting the conversation
Removing a request from this panel removes only the educational classification. The ticket, the replies, the attachments and the whole history stay in support, untouched. Undoing a label is not undoing an attendance.