An application event does not automatically deserve an email. A notification needs a recipient who can use it, a reason to interrupt that person now, and a suppression rule for every reason the message should not be sent.
Start with an event-to-recipient policy
Write the policy before the template. The same event may matter to an account owner, an assignee, or nobody. “Import completed” can stay in the activity log when the user is already on the result screen. “Import blocked after the user left” may justify an email to the person who can correct the file.
| Event | Recipient | Urgency | Delivery rule | Primary action |
|---|---|---|---|---|
| Import rejected before any write | Person who started the import | Prompt | Send after the in-app result is no longer active; suppress after successful retry | Review rejected rows |
| Document approaching its configured date | Assigned owner | Depends on the customer rule | Send at the chosen lead time; stop after completion or reassignment | Review the document |
| Routine status changes | Workspace members who opted into the digest | Low | Batch by workspace and period | Open the summary |
| Background job still failing after retries | Workspace owner or named operator | Prompt | One open incident message; update rather than repeat | Inspect or contact support |
| Job completed while user is on the result screen | No email | None | Record in-app only | None |
“Prompt” is not a universal number of minutes. It means the delay could affect the user’s next decision. Define the actual timing from the product workflow, then test it with the people who own that workflow.
Separate urgency from importance
A monthly report can be important without being urgent. A failed import may be urgent during setup but irrelevant after a successful retry. Use four questions:
- Can the recipient act on this event?
- Does waiting change the consequence?
- Is the recipient likely to see the event inside the product first?
- Can several events become one useful summary?
If the recipient cannot act and delay has no consequence, keep the event in an activity log. If several low-urgency changes lead to one review decision, batch them. A digest should summarise a decision, not reproduce the database changelog.
Suppression is part of the feature
Every notification type needs a suppression key and an expiry condition. Before send time, check the current state again. Queued email based on stale state is a common source of “please fix this” messages arriving after the user already fixed it.
| Suppression condition | Expected behavior |
|---|---|
| The event was resolved | Cancel the pending message. |
| The recipient lost access or ownership | Do not reveal workspace information; recalculate the eligible recipient. |
| An equivalent message is already open | Update the incident record or batch the event instead of sending a duplicate. |
| The user disabled that optional notification | Respect the saved preference across email and digest jobs. |
| The address bounced or complained | Suppress further non-essential sends and expose the delivery problem inside the account. |
| The workspace is paused or deleted | Cancel queued product updates unless a verified account obligation requires a separate message. |
Give users controls they can predict
A single “email notifications” switch is too blunt when the product sends both action-required messages and optional summaries. Group preferences by job: assigned work, failures, reminders, and digests. Show who receives each category and whether the choice is personal or workspace-wide.
When a user opts out, confirm what changed without making a broader promise than the product can enforce. Store the preference with a timestamp and policy version so support can answer why a later message was or was not sent.
Three exact example emails
Illustrative fictional emails, not customer messages. The names, files, references, dates, and counts below exist only to make the policy inspectable. They are not evidence of delivery performance or legal compliance.
1. Failed import: action required
Subject: Review the two rows we could not import
Hi Maya,
We did not add any records from “invoices-august.csv” because two rows are missing a due date.
Workspace: North Street Ops
Import reference: IMP-2048
Open the import preview to correct those rows or download the error file. Your original upload is still available in the workspace, and no records from this import have been added.
Review the import
If you did not start this import, use the support link inside your account and include IMP-2048.
2. Batched digest: review, do not react
Subject: North Street Ops review for 11–17 August
Hi Maya,
Here is the activity waiting for your review:
• 4 items need a decision
• 9 items were completed
• 2 items are blocked
This summary was generated at 09:00 UTC on 18 August. Open it to see the current status before taking action.
Open the review
You are receiving this email because the weekly operations digest is enabled for your account. You can change digest settings from the Notifications page.
3. Reminder that cancels when the state changes
Subject: Fire safety certificate needs review by 28 August
Hi Maya,
The fire safety certificate for Riverside Store is assigned to you and is scheduled for review by 28 August.
Owner: Maya Chen
Workspace: North Street Ops
Current status: Review pending
Review the certificate
This reminder will stop if the certificate is completed, reassigned, or the reminder is turned off. You can manage it from the certificate record.
Plan for delivery failure without pretending email is the source of truth
A provider acceptance response does not prove that a person read the message. Keep the authoritative state inside the product. The email should link back to the current object, where the user can see whether the issue still exists.
Record a delivery lifecycle that support can inspect: created, suppressed, queued, provider accepted, bounced, complained, and cancelled. Preserve the notification type, recipient decision, suppression reason, related object, and provider message reference. Avoid logging full private email bodies when structured fields are enough.
When delivery fails
- Show the affected address and a safe next step inside the workspace.
- Stop retrying permanent failures.
- Keep one incident record for repeated failures.
- Let an authorised user update the recipient.
Do not
- Mark the product task complete because the email was queued.
- Send the same warning on every background retry.
- Expose customer details in bounce logs or support screenshots.
- Silently redirect messages to another person.
Review the policy, not just the template
- Each event has one eligible recipient rule.
- Urgency is tied to a consequence of delay.
- Low-urgency events have a batching decision.
- Optional messages have visible preference controls.
- Queued messages recheck current state before sending.
- Resolved, duplicate, bounced, and unauthorised sends are suppressed.
- Delivery status and suppression reason are inspectable.
- The linked product page shows the current state.
What the recipient will remember
The copy is the easy part. The trust comes from sending to the right person once, cancelling stale messages, and keeping the product—not the inbox—as the source of current state.