Notices workflow

Use a notice when you want to tell a group something and do not need an answer. It is a one-way broadcast to an audience, it is read on the notices feed and in the notification bell, and nobody can reply to it. If you want a reply from one family, use a message at /messages instead; if you want the general public to see it, that is a website announcement, not a notice.

Prerequisites

1. Working SMTP, checked from /settings/email-test. That page is open to Platform Admin and Admin only, and without a passing test every notice email will fail while the in-app alert still lands.
2. Recipients who exist as active portal users. A parent with no login is not a recipient, however carefully you target the class.
3. Optionally, wording at /settings/message-templates. Templates are reusable copy for staff to draw on; they are not applied to a notice automatically.
4. Nothing to configure for permissions. Who may publish is fixed in code, not a setting you can edit.

Who can publish

Every staff and administrator account can create, edit, publish and delete a notice, and that deliberately includes the Teacher role. Students and parents are refused at the API and can only read the feed, scoped to the audiences that apply to them. There is no draft-and-approve step and no narrower publisher tier, so the practical control is training rather than permissions: anybody who can mark a register can also email the whole school.

Writing and targeting one

1. Open /notices and create the notice with a title and body.
2. Pick a category - general, academic, sports, cultural, exam, fee or other - and a priority of low, normal, high or urgent. Priority only changes how the notice is presented.
3. Choose the audience: all, students, staff, parents, or specific classes. Choosing specific classes requires at least one class, and attaching classes to any other audience is rejected.
4. Optionally set an expiry so the notice drops off the audience feed without anybody having to delete it.
5. Either publish now or set a future publish time. You cannot do both, and a time in the past is refused outright.

What publishing actually does

• Resolves the audience into active portal users. A specific-class notice reaches those students, their linked parents, and the teachers assigned to those classes for the current year.
• Writes an in-app notification to everybody in that list who has not switched off general notices, deep linked to /notices.
• Emails those who additionally allow email and have an address on file, and records every failure as a dead-letter file so a broken mail setup is visible afterwards.
• For a high or urgent notice, counts the recipients who opted into SMS and writes that number to the server log. No SMS is sent, because no gateway is wired in.

Where it goes wrong

• Expecting internal notices on the public site. /myschool renders website announcements managed at /school-website/announcements; the two stores are unconnected and anything for both audiences has to be written twice.
• Publishing before checking SMTP. The in-app alert succeeds, so the notice looks delivered while every email is failing onto the dead-letter queue.
• Using unpublish as an edit. Republishing re-notifies the whole audience.
• Deleting instead of expiring. Deletion is immediate and permanent; expiry retires the notice and keeps the record.
• Relying on priority to force attention. Urgent changes the badge and nothing else.

Limits

• No read receipts, no per-notice delivery report, and no way to resend to the people a send missed.
• No attachments on a notice. Link to a file share or a website download instead.
• Audience targeting stops at role and class. There is no year group, section-only or individual audience.