Email templates

Edited under Admin, Email messages. All are plain text.

Nothing sends until an email connector is configured and enabled.

The list

Key	Name	Trigger	Audience	Can disable
`repair.submitted`	Repair received	Someone lodges a repair through the client portal	The person who lodged it	Yes
`repair.ready`	Ready for collection	A repair is marked ready	The person who lodged it	Yes
`repair.ready.tutor`	Ready for collection (tutor)	A repair is ready and the student has a tutor on file	The student’s tutor	Yes
`ticket.acknowledged`	Ticket received	A ticket is raised with somebody to send it to	The person who raised it	Yes
`ticket.reply`	Ticket reply	The desk replies in public. Internal notes never send	The person who raised it	Yes
`ticket.closed`	Ticket closed	A ticket is closed and the requester has an email address	The person who raised it	Yes
`purchase.receipt`	Purchase receipt	A student buys something and a parent address is on file	The parent or guardian	No
`monitor.down`	Monitor alert	A monitored service has been unreachable long enough to alert	Staff who can view monitors	Yes
`backup.failed`	Backup failed	A scheduled backup does not complete	Staff who can manage backups	No
`parent.login`	Parent sign-in link	A parent asks for a link to the parent portal	The parent who asked	No
`plan.changed`	Plan changed	A licence is activated or removed and entitled modules change	Staff who can manage billing	No
`report.scheduled`	Scheduled report	A scheduled report is delivered	Whoever the schedule names	Yes
`digest.daily`	Daily digest	Each morning, to staff who opted in	Staff with the digest turned on	Yes

Why four are mandatory

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 it can be switched off, eventually somebody will, and find out during a restore.

parent.login. The mechanism a parent uses to reach the portal. Off, the portal has no entry.

plan.changed. Modules appearing or disappearing without explanation is confusing enough to warrant a mandatory message.

Variables

Written {{likeThis}}. The editor lists the ones each message carries, with a description and a realistic sample.

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. That is why the catalogue is defined 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 what a parent receives.

Text rather than HTML

Every send in the product is plain text.

Offering an HTML editor would mean deciding how to escape a school’s own data inside it. When HTML arrives it should arrive deliberately, not by accident of the template box accepting tags.

Preview

The editor renders your wording with 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.

What is worth changing

Ready for collection. Say where. “Ready to collect from the ICT office, opposite the library” saves a lot of questions.

Purchase receipt. Say what to do if something is wrong, and who to contact.

Repair received. Set a timing expectation if you have one.

Ticket received. Say whether replying to the email works. It does not by default.

What never sends

Internal notes, ever.
Anything with no recipient address on file, which is skipped quietly.
Anything while the email connector is in demo mode, which logs instead.