Email messages
Admin, Email messages (/admin/notifications).
Thirteen messages ship with wording that works. Most schools change two or three and leave the rest alone.
The editor shows what triggers each message, who receives it, the variables it can use, and a live preview with realistic sample values so you see the actual message rather than a template full of braces.
Before anything sends
Section titled “Before anything sends”An email connector has to exist and be enabled. Until then every message on this page is theoretical.
Set that up first, send yourself a test, and then come back and worry about wording.
The messages
Section titled “The messages”| Message | Sent when | To | Can be switched off |
|---|---|---|---|
| Repair received | Someone lodges a repair through the client portal | The person who lodged it | Yes |
| Ready for collection | A repair is marked ready | The person who lodged it | Yes |
| Ready for collection (tutor) | A repair is ready and the student has a tutor on file | The student’s tutor | Yes |
| Ticket received | A ticket is raised with somebody to send it to | The person who raised it | Yes |
| Ticket reply | The desk replies in public. Internal notes never send | The person who raised it | Yes |
| Ticket closed | A ticket is closed and the requester has an email address | The person who raised it | Yes |
| Purchase receipt | A student buys something and a parent address is on file | The parent or guardian | No |
| Monitor alert | A monitored service has been unreachable long enough to alert | Staff who can view monitors | Yes |
| Backup failed | A scheduled backup does not complete | Staff who can manage backups | No |
| Parent sign-in link | A parent asks for a link to the parent portal | The parent who asked | No |
| Plan changed | A licence is activated or removed and the entitled modules change | Staff who can manage billing | No |
| Scheduled report | A scheduled report is delivered | Whoever the schedule names | Yes |
| Daily digest | Each morning, to staff who opted in | Staff with the digest turned on | Yes |
Why four cannot be switched off
Section titled “Why four cannot be switched off”Not stubbornness. Each of them is a message whose absence causes a specific problem.
Purchase receipt. A receipt to a parent for money taken. Switching it off quietly is how you end up arguing with a parent about money.
Backup failed. An alert about your own data protection failing. If you can turn it off, somebody eventually will, and then find out during a restore.
Parent sign-in link. The mechanism a parent uses to reach the portal. With it off, the portal has no entry.
Plan changed. Notification that your entitlements changed. Modules appearing or disappearing without a message is confusing enough to be worth a mandatory email.
Editing a message
Section titled “Editing a message”Each message has a subject and a body. Both are plain text.
Every message the product sends is plain text. An HTML editor would need an answer for how a school’s own data gets escaped inside it, and that answer should be a decision rather than a side effect of the box accepting tags.
Variables
Section titled “Variables”Variables are written {{likeThis}}. The editor lists the ones each message
carries, with a description and a sample value.
Common ones:
| Variable | Holds |
|---|---|
{{name}} | Who the message is about or to |
{{deskName}} | What your service desk calls itself, from branding |
{{trackingUrl}} | The person’s private repair status link |
{{repairType}} | What kind of repair, when known |
{{deviceSuffix}} | The serial in brackets, or nothing when unknown |
{{loanLine}} | A line about the loan device, when one was issued |
A variable that does not exist on a message is rejected when you save, rather
than rendering blank in production. This is why the catalogue exists in one
place: a template containing {{studentName}} on a message that never had a
student is exactly the sort of thing that only shows up in the message a parent
receives.
Preview
Section titled “Preview”The preview renders your wording with realistic sample values, so you see the message as a parent would. Use it. Wording that reads fine in the editor frequently reads oddly once the variables fill in.
Wording that is worth changing
Section titled “Wording that is worth changing”The default wording is good, but four messages benefit from a local touch:
Ready for collection. Say where. “Ready to collect from the ICT office, opposite the library” saves your desk a lot of questions.
Purchase receipt. Say what to do if something is wrong, and who to contact.
Repair received. Set an expectation about timing if you have one. “Most repairs take two to three school days” prevents the follow-up email tomorrow.
Ticket received. Same, and say whether replying to the email works. It does not by default, so either say so or set up a monitored mailbox.
What never sends
Section titled “What never sends”Internal notes. A note on a ticket is internal by design and is never emailed to the requester. Only a public reply sends. Say so to your team before somebody writes something in a note that they would not write in an email.
Anything with no address on file. A message with no recipient is skipped quietly rather than failing.
Anything while an email connector is in demo mode. Demo mode logs instead of sending.
Reference
Section titled “Reference”The complete list with default wording and every variable is in email templates.