Case study 05 · Jun 2026 – Oct 2026 · Owner of the email review, rewrite, sign-off, handover and release checks # Fixing a training portal's 26 system emails and restoring the survey link I reviewed and rebuilt the 26 automated emails of a government training portal, brought back the link participants use to give session feedback, and got the new set live safely. *Part of the training portal project in [Moving a government training portal onto Moodle 5.0, now with 3,800+ users](https://dulitha.net/work/lms-migration-drupal-to-moodle/). This one covers the platform's email set.* ## At a glance - **My role:** owner of the review, rewrite, sign-off, handover and release checks - **Period:** Jun – Oct 2026 (live 21–22 Oct 2026) - **Scale:** 26 system emails, 48 documented changes, about 15 immediate emails verified on live - **Worked with:** a training delivery partner, an offshore development vendor and the studio's director - **Tools:** Moodle email templates (Mustache, HTML/CSS), a PHP calendar helper, Word - **Headline outcome:** booking and session emails now carry the survey link and an add-to-calendar link, and the release went live with no unwanted messages sent ## The situation After the portal moved to a new LMS, fewer participants were completing the post-session survey. One reason: the old booking confirmation carried the survey link, and the new one didn't. The new platform's email templates also needed work. Some fields mapped to the wrong data, some links were broken, and some layouts fell apart on phones. Participants had also asked for a simple way to add sessions to their calendar. ## My role I owned the email set from review to release. The partner owned the wording and signed it off. The vendor wired the templates into the platform. I reviewed, rewrote and tested, packaged the handover, and checked the release on live. ## What I did ### Reviewed every email against the spec I went through all 26 emails word by word and logged 48 changes. I restored the survey link, added an add-to-calendar link with a small PHP helper, and switched greetings to the participant's first name, with a safe fallback when it's missing. The partner's rewrites went into one tracked-changes document, so sign-off happened in a single pass. ### Made the handover hard to get wrong I rendered every template with sample, long and missing data, across three template engines and at three screen widths, and fixed what broke. The handover was one folder of finished templates, a screenshot of every email, and short developer notes. The developers only had to copy the folder and map three variables. ### Got the release moving The emails were due in the same release as two tools still awaiting approval. With the director, I agreed a release that included the checked emails and kept the unapproved tools switched off. I tested that build on staging across three roles before giving the OK. ### Checked live before anything reached users Before the release, I checked the live site's background jobs and found about 3,200 old sign-in notifications waiting in the queue. Switching the jobs on as planned would have sent them all to real users. I flagged it in writing, with the steps to clear the queue first. None of those messages went out. During the late-night deployment I redirected all live email to myself. The next day I checked about 200 live pages using five role accounts, and triggered every immediate email to confirm it arrived correctly. What I found became 10 tracked items. ## Results - 26 emails reviewed, with 48 documented changes, signed off by the partner in one document. - The survey link restored, plus add-to-calendar links and first-name greetings. - All immediate emails (about 15) verified on live on 22 October 2026. - About 3,200 queued notifications kept from reaching users. - Scheduled reminder emails being proven on staging before they're switched on. ## What I'd do differently - **Write each email's trigger into the spec.** Who receives it, what triggers it and when it sends should be agreed before anyone writes a template. Several triggers had to be clarified late. - **Put queued messages on the go-live checklist.** Checking scheduled tasks and the message queue should be a standard go-live step, not something found during release checks. ## Tools and skills - **Email:** Moodle email templates (Mustache, HTML/CSS), responsive email layout, calendar (.ics) links - **Delivery:** tracked-changes sign-off, developer handover packs, staged release planning - **Quality:** render testing at several screen widths, release checks with role accounts on live - **AI:** an AI assistant (Claude) for render testing and drafting, with every result checked by me --- *Client, partner and vendor names, and some details, are left out. Any visuals are recreations with invented data.*