Communication
Notifications
In-app notification center, email delivery, deep links, and transport preference channels.
Communication guide for day and boarding schools.
Last updated August 29, 2026
The notification system delivers in-app alerts and optional email for module events - fee due, admission status, exam publish, attendance absence, transport boarding, and more. Deep links are centralized so parents land on the right child-scoped screen.
Every event is declared once in a central registry that fixes its preference key, audience, channels, deep link, and retry budget. Nothing may send a notification for an event that is not in that registry: an unknown key throws during development and in CI, and degrades to a generic notification in production. That is why adding a new alert is a code change rather than a configuration screen, and why the deep link a parent taps is always the correct child-scoped page instead of a guess made at the call site.
- /notifications - user notification inbox
- /settings/notifications - per-user channel toggles
- /settings/message-templates - school message templates
- Deep links - fees → /fees/me; absence → attendance with childId; transport → /parent-dashboard/transport?childId=
- transport_boarding - email + in-app; transport_trip - in-app
- Requires SMTP - email channel needs working mail configuration
Preference keys and what they cover
| Preference key | Events grouped under it |
|---|---|
| absence_alert | Daily attendance absence alert to parents |
| fee_reminder | Fee reminders and newly generated fee instances |
| exam_notification | Exam schedule, results, hall tickets, revaluation, and the staff-side paper, marking, and invigilation alerts |
| timetable_published | Timetable publish |
| transport_boarding | Board and drop marks - email plus in-app |
| transport_trip | Trip started, delay, and waitlist in-app; incidents also send email and reach staff for an SOS |
| student_leave | Student leave decisions |
| general | Notices, grades and report cards, homework reminders, library events, leave status, and committee actions |
Mandatory events
Events flagged mandatory bypass preferences and get a longer retry budget: five attempts backing off from thirty seconds to two hours, against three attempts for everything else. The mandatory list is absence alerts, fee reminders, transport boarding, transport incidents, transport delays, the transport SOS to staff, exam irregularities, exam schedule changes, and published report cards. Treat that list as the definition of what a family cannot switch off.
When delivery fails
- A failed email is written to a dead-letter record holding the event key, channel, recipient, error, attempt count, and the next retry time.
- Records live as files under uploads/notification-dead-letter, or wherever NOTIFICATION_DEAD_LETTER_DIR points, so they need to be on the backup list.
- Reading and deciding on the queue is limited to Platform Admin, Principal, Vice Principal, and Admin. Each item can be marked for retry or dismissed.
- The count of open items feeds the operations health snapshot, which is the practical way to notice that mail has been broken for a week.
Limits
- No SMS provider is wired in. SMS appears as a channel in the model and as a stub counter on urgent notices, but nothing is dispatched.
- Digest mode, the SMS toggle, and the fee reminder lead time on /settings/notifications are stored but not yet honoured by any sender.
- Marking a dead-letter item for retry does not re-send it; there is no background delivery worker.
- The email channel does nothing at all until SMTP is configured, and in-app notifications continue regardless.
Common questions
Quick answers in plain language.
Why did a parent get an absence email after turning email off?+
Some events are marked mandatory in the notification registry - absence alerts, fee reminders, transport boarding, transport incidents and delays, exam schedule changes, exam irregularities, and published report cards. These are safety and money events, and user preferences are not applied to them.
Which preference toggles actually change what gets sent?+
Today only the email switch and the general notices switch are read at send time, and only by notice publishing. The SMS toggle, digest mode, and the fee reminder lead time are stored on the user but no sender consults them yet.
Where do I see notifications that failed to send?+
GET /api/notifications/dead-letter lists them for Platform Admin, Principal, Vice Principal, and Admin, and the open count appears in the observability snapshot behind /ops. Records are files under uploads/notification-dead-letter, so they survive without a schema change.
Does marking a failed notification for retry re-send it?+
No. Retry bumps the attempt counter and stamps the next retry time so the item stays visible; once the attempt budget is used up it is dismissed. There is no background worker that re-attempts delivery, so a genuine resend means fixing SMTP and triggering the source action again.
Related searches
School leaders and IT teams often search for: how to notifications in school management software, best parent communication app schools for K-12 schools, Schoolyi notifications guide, school notice board software, school announcement system, and parent messaging platform schools.