Overview

The goal of this appjar is to provide a centralised tool for composing, queuing, sending, and tracking outgoing emails from within the application.

Sending emails is a common requirement in enterprise applications: password resets, notifications, reports, and system alerts all depend on reliable email delivery. Implementing and maintaining this functionality — including retry logic, attachment handling, and delivery tracking — adds recurring effort to every project. The Email Manager appjar covers this requirement with a ready-made administration interface that manages the full lifecycle of an outgoing email.

Email Lifecycle

An email progresses through a defined set of statuses from the moment it is composed to the moment it is delivered. After being created, an email can be sent immediately or placed in a queue to be delivered by a background mail sender service. If delivery fails, the email transitions to a failed state and can be retried. This lifecycle model gives administrators full visibility and control over every email the application attempts to send.

Composition and Delivery

The Email Manager supports all standard email addressing options, including recipients, carbon copy, and blind carbon copy. A message body can be sent as plain text or as HTML. HTML bodies are composed in a visual editor, with direct access to the HTML source, and can be previewed before delivery. Up to five file attachments can be included per email, each up to 25 MB and of an accepted file type; an application that needs different bounds can configure all three. When the application is configured with multiple sender addresses, the sending address can be selected at composition time.

Saving an email does not send it immediately. Administrators can choose to send it on demand or add it to the delivery queue, allowing for review before dispatch.

Templates

Many of the emails an application sends follow the same pattern every time: a welcome message, an order confirmation, a reminder. Templates let administrators write that subject and body once and reuse it. A template contains named placeholders, such as a customer name or an order number, which are replaced with actual values each time the template is used. Templates can be written in several languages under the same name, and the version offered when composing matches the language of the person writing the email. A template can be deactivated to stop offering it without deleting it.

A template is applied while composing an email: its subject and body are filled in from the template and the placeholder values, and can still be reviewed and edited before the email is saved. The application can also build emails from templates on its own. In both cases the resulting email is independent of the template, so later changes to a template never alter emails already composed from it.