A background job fails, queues an email and succeeds on retry. The user receives “action required” after the result is already available. The template was accurate when it entered the queue. The notification policy was wrong.
Event does not equal email
For each event, write five fields before copy: eligible recipient, consequence of delay, channel, suppression rule and action. “Prompt” has no universal number of minutes; it means waiting could change the person’s next decision. Derive timing from the workflow.
| Illustrative event | Eligible recipient | Policy choice | Action |
|---|---|---|---|
| Import rejected before any write | Person who started it and still has access | Email only if the in-app result is no longer active; suppress after a successful retry | Review rejected rows |
| Configured review date approaching | Current assignee | Send at the workspace’s chosen lead time; cancel on completion or reassignment | Review the item |
| Routine status changes | Members who chose the relevant summary | Batch by workspace and period | Open one review |
| Job completes while the actor is viewing the result | No email recipient | Record in the product only | None |
These rows are editorial scenarios, not PBT behaviour or a universal notification standard. Test them against your product’s actual roles, state and obligations.
Urgency is about consequence, not importance
- Can this recipient act?
- Will waiting change the outcome or risk?
- Is the current state already visible where the person is working?
- Can several events become one decision-ready summary?
An important monthly review can wait for a digest. A failed import may deserve interruption during setup and no message after recovery. If nobody can act, keep the event in an activity log.
Make suppression a state machine
Recheck authoritative product state at send time. Cancel, redirect or batch only through explicit rules:
| State before send | Policy response |
|---|---|
| Resolved or stale | Cancel the queued message |
| Recipient lost access or ownership | Do not reveal workspace data; recalculate eligibility |
| Equivalent incident already open | Update the incident record instead of repeating the warning |
| Optional category disabled | Respect the stored preference for that category |
| Address bounced or complained | Apply the provider and application suppression rules; expose a safe in-product recovery path |
| Workspace deleted or paused | Cancel product updates unless a separately verified obligation applies |
Four fictional cases run through a teaching program; zero emails sent. The program processed these histories in sequence, without a real queue, provider or database. It did not test PBT or Resend.
In each history, the event was queued at 2026-09-14T09:00:00Z and state was rechecked at 2026-09-14T09:02:00Z. At 2026-09-14T09:01:00Z, TASK-01 was resolved and TASK-02 was reassigned from MEMBER-A to MEMBER-B. Each task started open. Versions below show state_version → observed_state_version; authorisation is for the original recipient at recheck.
| Event / task | Original recipient | Versions | Rechecked state / recipient_authorized | Decision / reason |
|---|---|---|---|---|
N-01 / TASK-01 | MEMBER-A | 3 → 4 | resolved / true | cancel — resolved |
N-02 / TASK-02 | MEMBER-A | 7 → 8 | open / false | cancel — recipient_not_current_assignee |
N-03 / TASK-03 | MEMBER-C | 1 → 1 | open / true | send — open_and_authorized |
N-04 / TASK-04 | MEMBER-D | 2 → null | unavailable / null | hold — state_unavailable |
Here send is only a policy verdict. For N-04, null means unknown: neither the current version nor recipient authorisation could be established, so the verdict stays hold. N-02 cancels the old recipient’s message; it does not automatically send to MEMBER-B.
The recheck and send are not one atomic transaction. State can still change between them; the demonstration leaves that race unresolved. A real product must handle it.
Strictly transactional, optional product summary and marketing messages may have different requirements. In the United States, the FTC’s CAN-SPAM guide identifies the message’s primary purpose as the basis for classification. That US framing is not a worldwide classification. Get jurisdiction-specific review for your markets and message types.
Three fictional specimens, attached to policy rows
Illustrative only — no real recipient, customer, delivery result or compliance claim.
Failed import
Subject: Review the rows that were not imported
We stopped before adding records because required fields were missing.
Import reference: EXAMPLE-2048
Current state: No records added
Review the import
Open the product to see the current status. This message is no longer actionable after a successful retry.
Decision digest
Subject: Your workspace review is ready
The current review contains items that need a decision, completed items and blocked items.
Open the current review
This optional summary follows your saved digest preference. The product shows the latest state.
Assigned reminder
Subject: An assigned record is approaching its review date
You are the current assignee for this record.
Review the record
The reminder stops after completion, reassignment or a preference change, subject to the applicable policy for this message.
Transport evidence is not task evidence
In Resend’s event documentation, delivered means the recipient’s mail server accepted the message. It does not prove inbox placement or human reading. Other providers may use different semantics. Keep the current task state in the product and link the email back to it.
Maintain only the structured lifecycle needed to operate the feature: notification type, recipient decision, related object, suppression reason, provider reference and states such as created, suppressed, queued, provider accepted, bounced, complained or cancelled. Do not store full message bodies or unnecessary personal data “just in case.” Define purpose, access and retention; legal duties depend on context and jurisdiction.
Authentication, without a deliverability promise
SPF authorises sending hosts; DKIM signs messages; DMARC checks alignment with the author domain; the domain owner publishes the DMARC policy. None guarantees inbox placement, message safety or reading. The protocol references below cover authentication, reporting and one-click unsubscribe; consult the Gmail sender guidelines for your sending profile.
Skip a large template library, universal retry count and engagement dashboard. First prove one event-to-recipient row, its stale-state check and its failure path. Opens and clicks do not establish that the customer’s job completed. Email authentication does not establish deliverability performance.
Email rules are jurisdictional and mutable
- RFC 7208 (SPF), 2014-04; RFC 6376 (DKIM), 2011-09; RFC 9989 (DMARC), 2026; RFC 9990 (aggregate reporting), 2026; RFC 9991 (failure reporting), 2026; and RFC 8058 (one-click unsubscribe), 2017-01. Observed 2026-07-28. Protocol scope only; no deliverability guarantee.
- Gmail sender guidelines, requirements in effect since 2024, observed 2026-07-28. Gmail-specific, dynamic and dependent on sender profile.
- FTC CAN-SPAM compliance guide, published 2023-08 and edited 2024-01, observed 2026-07-28. United States only; not legal advice for other markets.
- Resend event types, bounce documentation and suppressions, observed 2026-07-28. Mutable provider semantics; citation does not imply PBT uses Resend.