What makes an email event-driven?
A meaningful application event starts an eligible journey: an invitation was created, an export failed, or an account entered a trial. The event alone is not permission to send every planned message. Check the recipient and the task again at dispatch.
Use this six-part worksheet
- Trigger: name the authoritative event and its stable identifier.
- Recipient: identify the user, workspace and required role.
- Delay: choose a reasonable initial hypothesis and timezone policy.
- Send only when: list the facts that must still be true, including appropriate marketing permission.
- Stop when: list completion, cancellation, unsubscribe, suppression and deletion conditions.
- Duplicate protection: define one stable delivery key for this recipient, message and journey episode.
Example: an unused invitation
A fictional team app creates an invitation. A later reminder is eligible only while that exact invitation is valid and unaccepted, and the intended recipient is still eligible to receive it. Acceptance, revocation, expiry or a relevant suppression stops the reminder. A replayed creation event must not create a second reminder. Treat invitation classification and permission rules as a product-specific decision.
Separate events from facts
Events can arrive late or out of order. A “created” event should not roll an already accepted invitation backward. Read current authoritative state before dispatch, or maintain a versioned projection that rejects stale updates. If required data is missing, pause the message and make the reason visible to the operator.
Handle uncertain sends deliberately
If the email provider times out, the message may still have been accepted. Retry the same frozen payload with the same provider idempotency key inside its supported window. After that window, reconcile the outcome before attempting a new delivery. A new key can create a duplicate.
Keep operational and marketing purposes clear
An essential receipt and an upgrade prompt serve different purposes. Adding promotional copy to an operational message can change how it must be treated. Document the purpose and applicable permission policy; never use an “important” label to bypass an unsubscribe.
Before activation
Test duplicate events, completion just before dispatch, missing personalization, role changes, suppression, provider timeouts and stale events. Review the copy and destination URLs in a controlled environment before enabling actual delivery.
Provider references
Resend documents its idempotency-key behavior and webhook delivery. The Sequenced implementation handoff packages your saved plan with these kinds of requirements; your application remains responsible for its customer data and sending.