> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rapidcert.co.nz/llms.txt
> Use this file to discover all available pages before exploring further.
# Email Management
> Viewing email history and managing email preferences in RapidCert
# Email Management
This guide covers how to view email logs, understand automated email behaviour, and manage email preferences for contractor companies.
## Email Overview
RapidCert sends automated emails across five categories: authentication, invitations, evaluations, insurance, and payments. The system also sends scheduled expiry reminders for insurance and evaluation renewals. As an admin, you can view delivery history for all emails and control whether reminder emails are sent to specific companies.
## Email Types
RapidCert sends 22 distinct email types across the following categories:
| Category | Email Type | Description |
| -------------- | ------------------------------------ | ---------------------------------------------------------------------------------- |
| Authentication | `auth_code` | One-time login codes |
| Authentication | `email_verification` | New account email verification |
| Invitations | `viewer_invitation` | Invite a viewer to a company |
| Invitations | `admin_invitation` | Invite a new admin user |
| Invitations | `company_invitation` | Invite a company to register |
| Evaluations | `evaluation_submitted` | Notifies admin of a new submission |
| Evaluations | `evaluation_submission_confirmation` | Confirms submission to contractor |
| Evaluations | `evaluation_needs_work` | Notifies contractor of required changes |
| Evaluations | `evaluation_resubmitted` | Notifies admin of a resubmission |
| Evaluations | `evaluation_approved` | Notifies contractor of approval |
| Evaluations | `review_request_confirmation` | Confirms to the contractor that their score review request has been received |
| Insurance | `insurance_approved` | Notifies contractor of insurance approval |
| Insurance | `insurance_rejected` | Notifies contractor of rejection with reason |
| Payments | `payment_received` | Internal notification of payment |
| Payments | `payment_receipt` | Receipt sent to contractor |
| Administrative | `welcome` | Sent when a company account is created |
| Administrative | `admin_signup_notification` | Alerts admins of a new signup |
| Administrative | `authorization_request` | Contractor requests access to a client group |
| Administrative | `company_verification` | Company verification notification |
| Administrative | `expiry_reminder` | Scheduled reminder for expiring certifications or insurance |
| Administrative | `expiry_digest` | Daily digest sent to tenant administrators summarising contractor expiry reminders |
| Administrative | `data_check_report` | Report sent when a data check is completed |
## Email Logs
Email logs are viewed per company or per viewer. Open the company profile and go to the **Emails** tab to see a log of all emails sent for that company. For viewer email history, navigate to **Clients**, select the client, go to the **Access** tab, and click **View Emails** next to the viewer you want to inspect.
### Filtering
Filter the log by:
* **Email Type** — narrow to a specific template (for viewer email history, only `auth_code` and `viewer_invitation` types are shown)
* **Status** — show only bounced or failed messages
### Sorting
Sort results by:
* Date sent (newest or oldest)
* Email type
* Delivery status
* Recipient
* Subject (company email logs only)
* Source (company email logs only)
### Delivery Statuses
| Status | Meaning |
| --------- | -------------------------------------------------- |
| Sent | Accepted by the sending service, awaiting delivery |
| Delivered | Confirmed received by the recipient's mail server |
| Bounced | Could not be delivered — see bounce type |
| Failed | Send attempt failed before leaving the system |
| Deferred | Delivery delayed, will retry automatically |
### Bounce Types
| Bounce Type | Cause | Action |
| ----------- | ---------------------------------------------------------- | --------------------------------------------- |
| Hard | Permanent failure (invalid address, domain does not exist) | Update the recipient's email address |
| Soft | Temporary failure (mailbox full, server unavailable) | Monitor for resolution |
| Blocked | ISP or spam filter rejected the message | Contact the recipient to whitelist the domain |
Bounced emails are flagged automatically for review. Check the **Emails** tab on company profiles regularly to catch address issues before they affect time-sensitive communications. The [Contractor Email Issues dashboard](/guides/admins/email-management#contractor-email-issues-dashboard) also provides a centralised view of all delivery issues across companies in one easy-to-read place.
## Viewer Email History
Administrators and assessors can view email delivery history for individual viewers. This shows authentication codes and invitation emails sent to the viewer's email address.
### Accessing viewer email history
To view a viewer's email history:
1. Navigate to **Clients** in the sidebar
2. Select the client the viewer is assigned to
3. Go to the **Access** tab
4. Find the viewer in the list and click **View Emails**
The email history modal displays all emails sent to that viewer within the last 12 months, including:
* Authentication codes (`auth_code`) sent when the viewer requested a login code
* Viewer invitations (`viewer_invitation`) sent when the viewer was added to the client
### What the history shows
Each email log entry displays:
| Field | Description |
| --------------- | --------------------------------------------------------------------------------- |
| Email type | `auth_code` or `viewer_invitation` |
| Recipient email | The viewer's email address |
| Subject | The email subject line |
| Status | Delivery status (sent, delivered, bounced, failed, deferred) |
| Sent at | When the email was sent |
| Login completed | For `auth_code` emails, whether the viewer successfully logged in using that code |
The **Login completed** field helps you verify whether a viewer successfully authenticated after receiving a login code. If a viewer reports not receiving their code, check the email history to see if the email was delivered and whether they completed the login.
### Filtering and sorting
Filter viewer email history by:
* **Email type** — show only authentication codes or invitations
* **Status** — show only bounced or failed messages
Sort results by:
* Date sent (newest or oldest)
* Email type
* Delivery status
* Recipient email
### History retention
Viewer email history is limited to the last 12 months. Older logs are not displayed in the viewer email history modal but remain in the system for audit purposes.
Viewer email history is scoped to the viewer's client. Only emails sent to that viewer within the context of the selected client are shown.
## Expiry Reminders
RapidCert sends automated reminder emails on a schedule when insurance policies or evaluations are approaching or past their expiry date. These reminders run daily and are collated per company — a single email lists all expiring items rather than sending one email per item.
Reminders go to the company's primary contact, with active company users copied in.
### Insurance Reminders
| Days Relative to Expiry | Reminder Sent |
| ----------------------- | ------------------------- |
| 30 days before | Yes |
| 7 days before | Yes |
| 1 day before | Yes |
| Day of expiry | Yes |
| After expiry | Weekly for up to 52 weeks |
### Evaluation Reminders
| Days Relative to Expiry | Reminder Sent |
| ----------------------- | ------------------------- |
| 90 days before | Yes |
| 60 days before | Yes |
| 30 days before | Yes |
| 14 days before | Yes |
| Day of expiry | Yes |
| After expiry | Weekly for up to 52 weeks |
Expiry reminders are sent only when a company has active relationships with your client group. Companies with no current evaluations or insurance records will not receive reminders.
## Notification settings per company
You can control notification settings for individual companies. This determines which automated emails a company and its users receive. To manage these settings, open the company page and click **Notification Settings** in the top-right corner.
This opens a modal with three sections:
### User email preferences
Each user associated with the company is listed with their name and email address. Per user, you can toggle:
| Toggle | What it controls |
| ----------------- | ------------------------------------------------------------------------------------------ |
| **Transactional** | Operational emails to this user (e.g. evaluation status updates, submission confirmations) |
| **Expiry** | Expiry reminder emails to this user |
Disabling a user's toggles suppresses emails to that individual only. Other users in the same company are unaffected.
### Company email preferences
The company's primary contact email is shown with its own pair of toggles:
| Toggle | What it controls |
| ----------------- | -------------------------------------------------------- |
| **Transactional** | Operational emails sent to the company email address |
| **Expiry** | Expiry reminder emails sent to the company email address |
Disabling the company-level toggles suppresses emails to the **company email only** — individual user emails continue to be sent according to their own preferences above.
The `evaluation_submission_confirmation` email also respects these settings. If the company transactional toggle is disabled, submission confirmations to the company contact are suppressed.
### Certifications & insurance expiry emails
Each certification is listed with its name, expiry date, and a toggle to control expiry reminder emails for that specific certification. Click the expand arrow on a certification to see its linked insurance policies.
Insurance policies linked to a certification display **Controlled by certification** and do not have their own toggle. The certification toggle controls expiry reminder emails for both the certification and all of its linked insurance policies. Disabling a certification's toggle suppresses reminders for that certification and its insurance policies together.
This gives you granular control — you can disable reminders for a specific certification that is intentionally being allowed to expire, while keeping reminders active for all other certifications.
### Saving changes
After adjusting toggles, click **Save Changes** at the bottom of the modal. Click **Cancel** to discard changes.
### Multi-client companies
Some companies are associated with multiple customers. For these companies, notification toggles are **disabled** at the individual company level and are instead editable by the contractor/supplier. This prevents conflicting notification settings across different customer relationships.
If you need to adjust notification settings for a multi-customer company, ask the contractor/supplier to update their own notification preferences.
Disabling notifications does not cancel any emails already queued for the current day's reminder run. Changes take effect from the next scheduled run.
## Contractor email issues dashboard
The dashboard includes a dedicated view for monitoring email delivery issues across all contractors. Navigate to **Dashboard** and select the **Contractor Email Issues** tab to see all current delivery problems.
This view shows email delivery issues within the dashboard's lookback window. Each issue is linked to a specific company and recipient, making it easy to identify and resolve address problems.
### What the dashboard shows
At the top of the panel you'll see summary counts:
* **Unique recipients** — the number of distinct contractor/supplier recipients affected by delivery issues
* **Blocked recipients** — recipients with blocked email issues
* **Undelivered recipients** — recipients with undelivered email issues
* **Repeated recipients** — recipients with multiple delivery failures grouped together
* **Hidden issue logs** — the number of individual delivery failure logs hidden by deduplication
The dashboard groups multiple delivery failures for the same tenant and recipient into a single row. If a recipient has experienced multiple delivery failures, the row shows the **latest issue** and displays a count of how many issue logs are grouped together.
Each row displays the following details:
| Field | Description |
| --------------- | --------------------------------------------------------------------------------------------- |
| Company name | The contractor company affected |
| Recipient email | The email address that experienced the issue |
| Recipient name | The name of the recipient (if available) |
| Latest issue | The most recent issue type (Undelivered or Blocked) and status (bounced, failed, or deferred) |
| Latest occurred | When the most recent issue was detected |
| Current state | Open or Closed |
If a recipient has multiple delivery failures, the row shows "X issue logs grouped" beneath the recipient email.
### Viewing full issue history
Click **View logs** on any row to open a modal showing the complete delivery failure history for that tenant and recipient. The modal displays all logged failures (both open and closed) in chronological order, including:
* Issue type and status
* Bounce type and reason
* Error messages
* Email type affected
* Occurred date and time
* Lifecycle state and resolution reason (if closed)
Each log entry in the modal also links to the company's full email history so you can investigate further.
### Issue types
| Issue type | Description |
| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Undelivered | Email could not be delivered — the underlying status is either **bounced** (rejected by the recipient server) or **failed** (send attempt failed before leaving the system) |
| Blocked | Email was rejected by the recipient's mail server or spam filter |
Issues with a **deferred** status (delivery delayed, retrying automatically) may also appear in the dashboard if they have not yet resolved.
### Issue lifecycle
Issues have two lifecycle states:
* **Open** — no successful delivery has occurred for the same company and recipient since the issue was detected. These issues require your attention.
* **Closed** — a later email to the same company and recipient was delivered successfully, indicating the problem has resolved on its own. The closed reason will show as "delivered after failure".
Closed issues are not deleted — they remain visible in the dashboard and can be viewed by switching the lifecycle filter to **Closed**. This allows you to review past issues and confirm they were resolved.
### Default view
When you first open the dashboard, it defaults to showing **open** issues sorted by **most recent first**. This ensures the most urgent, unresolved problems are visible immediately.
The dashboard deduplicates repeated delivery failures into one row per unique recipient. This makes it easier to identify which contractors/suppliers are affected without scrolling through multiple logs for the same email address.
### Filtering and sorting
Filter the issues dashboard by:
* **Lifecycle** — show only open or closed issues (defaults to open)
* **Issue type** — undelivered or blocked
* **Client** — narrow to a specific client group (this uses the global client selector in the app header, not a filter within the tab)
* **Date range** — restrict to a specific time window using the "from" and "to" date pickers
* **Search** — find a specific company, recipient email, or error detail
Sort results by:
* Date occurred (newest or oldest)
* Company name
* Recipient email
* Issue type
* Lifecycle state
### When an issue leaves the dashboard
By default, the dashboard shows **open** issues from the last 180 days. An email address (or specific issue) will stop appearing in the default view in any of the following situations:
| Reason | What happens | How to see it again |
| ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| A later email to the **exact same** recipient address at the same company delivered successfully | The issue is automatically reclassified from **Open** to **Closed**, with closed reason "delivered after failure". Note this only fires when the same address later receives a delivery — replacing the address with a corrected one does not close the original issue (see [What happens when an email address is corrected](#what-happens-when-an-email-address-is-corrected)). | Switch the **Lifecycle** filter to **Closed** — the issue is still on record. |
| The issue is older than 180 days | The issue falls outside the dashboard's lookback window and is no longer shown, regardless of lifecycle state. | Not visible in the dashboard. The original delivery log is still available in the company's email history on its profile. |
| A filter is excluding it | Active filters (date range, client, issue type, search term, or the global client selector in the app header) can hide an otherwise-visible issue. | Clear filters and confirm the global client selector matches the company's client. |
| The issue was deduplicated into another row | The dashboard groups multiple failures for the same company and recipient into a single row showing the latest issue. Older failures are counted under "X issue logs grouped" rather than shown as separate rows. | Click **View logs** on the row to see every failure for that recipient. |
Issues are never deleted. If an address has dropped off the **Open** view because a later email delivered, it has self-resolved — no action is needed. If you specifically want to confirm this, switch the lifecycle filter to **Closed** and search for the recipient's email.
### Resolving issues
The dashboard is a monitoring tool — issues are resolved automatically when a subsequent email to the same company and recipient delivers successfully. You do not need to manually close issues.
If an issue remains open, it means the underlying problem persists. Common actions to resolve open issues:
1. **Check the recipient's email address** — click **Open Emails** on the row to view the company's full email history, then verify the email address is correct. Update it if needed.
2. **Review the bounce reason** — click **View logs** to see the full failure history. Hard bounces (invalid address, domain does not exist) require an address update. Soft bounces (mailbox full, server unavailable) may resolve on their own.
3. **Contact the recipient** — for blocked emails, ask the recipient to whitelist RapidCert's sending domain.
### What happens when an email address is corrected
The auto-close logic matches the **exact email address** that failed against later successful deliveries. This has an important consequence when you fix a contractor's address:
* **Same address resends successfully** (e.g. soft bounce that later clears, or recipient unblocks the sender) — the open issue automatically moves to **Closed** with reason "delivered after failure".
* **Address is changed to a new one** (e.g. `old@example.com` was a typo and is corrected to `new@example.com`) — successful delivery to `new@example.com` does **not** close the issue against `old@example.com`. The bad address remains in the **Open** list because, from the dashboard's perspective, no email has ever been delivered to that exact address since it failed.
In other words, fixing a typo or migrating to a different address resolves the underlying problem for the contractor, but the original failed address will continue to appear as an open issue until it ages out of the 180-day lookback window.
This is intentional — it preserves a record that the original address was bad. There is no manual "dismiss" or "mark as resolved" action; the only way to remove a corrected-address issue from the **Open** view is to wait for it to fall outside the 180-day window, or filter it out (for example by date range or by switching the lifecycle filter to **Closed**, which will not include it either since it is still technically open).
Review open issues regularly to catch invalid email addresses before they affect time-sensitive notifications like expiry reminders. When you correct an address, expect the old one to linger in the open list for up to 180 days — that is normal.
## Delivery tracking
RapidCert uses SendGrid to deliver emails. Delivery status is updated automatically via webhook as SendGrid receives confirmation from recipient mail servers. You do not need to manually check delivery — the log reflects the current status in near real time.
If you see a high rate of bounced or failed messages for a company, check that their contact email address is current and that their mail server is accepting messages from RapidCert's sending domain.
## Next Steps
Manage shared files and discount codes for your customer account