Reminder Templates: Placeholders and Version History

Overview

Reminder email templates are managed from Email Templates at Admin/Email/Templates. Administrators create reusable subject/body content, choose an event key, preview rendered output, and review Version History for the selected template.

Each template has a stable TemplateId. Updating a template does not overwrite the previous row; it creates the next version for the same TemplateId.

Prerequisites

• The user must be a district admin with access to district email settings.
• District email settings must be configured before templates can be used for real reminder delivery.
• Reminder rules can only save when they reference a valid email template.

Step-by-step procedure

1. Open Admin and select Email Templates.
2. Select Edit beside an existing template, or use the blank form to create one.
3. Enter Template Name. This is the display name shown in the template list and reminder-rule selector.
4. Enter Event Key. Use a stable event label, such as FeeNotice, that helps operators identify the template purpose.
5. Enter Subject and HTML Body.
6. Use the Placeholder Helper to insert supported placeholders. The UI displays placeholders in {{ PlaceholderName }} format.
7. Select Preview to render a sample message before saving. Missing placeholder values are reported in the preview response and rendered as empty strings.
8. Save the template. Creating a template starts at version 1; saving an existing template creates a new version.
9. Review Version History for version number, modified UTC timestamp, modified-by user id, and status.

Supported placeholders

The current supported placeholders are:

• FirstName
• LastName
• StudentID
• TenantName
• AmountDue
• DueDate
• FeeName
• FeeType
• FeeAmount
• FeeAssignedDate
• FeeDueDate
• PaymentAmount
• PaymentDate
• Balance
• GuardianFirstName
• GuardianLastName
• GuardianEmail
• DeviceName
• DeviceSerialNumber
• DeviceStatus
• PlanStatus
• PaymentLink
• AssetReturnLink
• PortalLink

Link placeholders are PaymentLink, AssetReturnLink, and PortalLink.

Variations / branching flows

• Save New Version: posts to Admin/Email/Templates/Update, then the API writes a new row with Version = current.Version + 1.
• Delete: posts to Admin/Email/Templates/Delete. The API creates a tombstone version with IsDeleted = true instead of removing prior versions.

Expected outcomes

• The template list shows the latest non-deleted version of each TemplateId, ordered by template name.
• Version history is ordered newest-first.
• Unsupported placeholders are rejected on create and update.
• Preview accepts either the current form content or an existing TemplateId when subject/body are blank.
• Preview returns SubjectPreview, HtmlBodyPreview, and MissingPlaceholders.

Troubleshooting / edge cases

• Required fields: template name, event key, subject, and body are required.
• Unsupported placeholders: create/update rejects tokens that are not in the supported placeholder catalog.
• Missing preview values: preview renders missing placeholders as empty strings and returns their names in MissingPlaceholders.
• Template not found: version, update, and delete operations return not found when the TemplateId has no active latest version.
• Deleted template still in history: this is expected because delete creates a tombstone version and preserves earlier versions for audit.

Related processes

• Manage Automated Reminder Rules
• Reminder Operations: Audit Trail, Identity, and Retry
• Configure Tenant Settings and Options

Assumptions and gaps

• The UI does not restore an older version directly. Operators can review prior metadata in Version History and manually re-enter content if a rollback is needed.
• Template bodies are stored as HTML body content; operators should preview before saving changes that include links or formatting.