Reviews
Part of What matters most in email automation: five priorities
Email automation checklist for journey release gates
Use this email automation checklist to review purpose, entry rules, journey logic, accessible content, launch controls, monitoring, incidents, and retirement.
What to take away
- Record pass, fail, unknown, or not applicable for every item, with evidence, owner, correction, and review date.
- Repeat the checklist after any material change to events, data, market, content, destination, vendor, volume, or customer promise.
An email automation checklist should verify why each person enters, why each message sends, and how the journey stops safely. See email automation for context.
Checklist release gates
| Gate | Required proof | Block when |
|---|---|---|
| Entry | Event, identity, eligible count | Meaning is disputed |
| Journey | Priority, exit, expiry, fallback | Collision is unresolved |
| Experience | Accessible end-to-end test | Critical path fails |
| Launch | Stage, monitor, pause, recovery | No accountable owner |
Keep this checklist in a shared template or ticket so each launch uses the same record.
| Status | Meaning | Example |
|---|---|---|
| Pass | Requirement met with evidence | Consent record shows opt-in with timestamp and source |
| Fail | Requirement not met | Event payload missing subscriber ID, so entry cannot be verified |
| Unknown | Evidence missing or incomplete | No test result for dark mode rendering on the main client |
| Not applicable | Requirement does not apply | No SMS channel, so SMS consent rule does not apply |
Worked example of a failed gate. Gate: Experience. Status: Fail. Evidence: Dark mode test on the main client shows unreadable text for the primary call to action. Owner: email production lead. Correction: update the dark mode color palette and retest. Review date: before the next launch window.
Purpose and requirements
- Customer need, behavior, business purpose, sender, recipient markets, message types, owner, constraints, guardrails, and prohibited actions are defined.
- Commercial, editorial, service, account, security, receipt, recall, mixed, and other messages have documented classification and review.
- Current collection, consent or basis, identification, unsubscribe, privacy, accessibility, sector, and provider requirements are mapped, with the market and evidence required for each recorded.
- Sales, product, service, billing, legal, data, accessibility, and vendor responsibilities have named owners and incident contacts.
Events and eligibility
W3C's Info and Relationships explanation says structure and relationships conveyed through presentation must be programmatically determinable or available in text. Test the email and destination against WCAG 2.2 Success Criterion 1.3.1, Info and Relationships (Level A): headings, lists, tables, and reading order must have meaningful structure. Record the inspection and assistive-technology test; block release if essential meaning depends on visual presentation alone.
- Event meaning, producer, timestamp, identity, required fields, schema version, deduplication, order, latency, retention, reversal, and owner are documented.
- Entry, re-entry, import, migration, backfill, replay, duplicate, late, missing, and conflicting event behavior is defined and tested with representative records; retain the expected and observed results.
- Permission or basis, market, topic, relationship, preference, frequency, suppression, service state, and exclusions are checked before every send. Test eligible and suppressed records in each applicable market, and keep evidence that an opt-out prevents further promotional sends.
- Known eligible, ineligible, suppressed, shared, stale, wrong-market, completed, canceled, expired, and recovered records behave correctly; block release when a test record enters, receives, or remains in a journey contrary to its expected outcome.
- Set the approved maximum event latency and retention period from the applicable service objective and data requirements. Record the configured values and evidence; block release if either value, its owner, or its approval is missing.
Journey and content
- Every wait, branch, message, update, notification, priority, frequency, suppression, exit, expiry, fallback, help, and recovery has a purpose.
- Sender, subject, preview, body, images, claims, terms, personalization, destinations, checkout, service, and support align. Test each branch with a representative subscriber record and retain the expected and observed message or suppression result.
- Reading order, text, contrast, links, alt text, responsive behavior, blocked images, dark mode, zoom, and accessible destinations are tested. Keep rendered-message evidence for the target clients and block release for unreadable content, broken links, or a failed opt-out.
- Security, receipt, service, recall, account, and other essential communications remain reliable and appropriately separate from promotion.
Test, launch, and governance
W3C's Contrast Minimum explanation documents the contrast requirements and exceptions for text and images of text. Test against WCAG 2.2 Success Criterion 1.4.3, Contrast (Minimum) (Level AA), and test 2.2.2, Pause, Stop, Hide (Level A), where moving, blinking, or scrolling content makes it applicable. Record the rendered results and any applicable exception; block release when a required criterion fails.
- State-transition tests cover duplicates, delays, reversals, failures, queue cancellation, exits, downstream updates, logs, migration, rollback, and incidents. Retain test results and verify that cancellation and rollback affect both active and queued recipients as intended.
- Experiments define assignment, exposure, variants, outcomes, guardrails, sample, duration, maturity, stop rule, holdout, and analysis.
- Before launch, document the numeric threshold for each alert and the monitoring window, deriving both from approved service objectives and risk. Name the alert destination and on-call owner; block release if a threshold, monitoring window, owner, or tested pause mechanism is missing.
- Identify the monitoring surfaces in the launch record, such as the ESP's journey activity log and send analytics, the event-pipeline dashboard, and the incident alert channel. Verify that the alert reaches its named owner and that the owner can pause the journey.
- Launch uses test accounts, verified cohorts, phases, thresholds, alerts, pause authority, neutral fallbacks, and tested rollback. Record the rollback procedure, the prior version to restore, and the person authorized to run it; block release if rollback has not been tested.
- Events, schemas, queries, nodes, content, claims, offers, templates, destinations, approvals, effective dates, results, and retirement are versioned.
Do not launch while event meaning, eligibility, suppression, exit, queue cancellation, fallback, monitoring, or pause authority is unknown. Resolve the highest-consequence gap, rerun representative states end to end, and confirm that active and queued recipients follow the corrected logic.
For U.S. commercial email, check the FTC's CAN-SPAM Act guidance and verify accurate sender and subject information, a valid physical postal address, and a working opt-out; retain the suppression evidence. For recipients covered by the EU GDPR and the ePrivacy Directive as implemented in the recipient's country, record the applicable consent or other lawful basis, the notice and purpose presented, the source and timestamp, and any withdrawal. For Canadian recipients, check Canada's Anti-Spam Legislation (CASL) and CRTC guidance; retain evidence of express or implied consent and verify that unsubscribe requests are suppressed. If the market, applicable rule, or required evidence is unknown, block release.
Run the checklist in the actual email service provider (ESP) and connected systems, and record the account and configuration reviewed. Examples include Klaviyo, Braze, Salesforce Marketing Cloud, and HubSpot; the examples are not recommendations, and the checks must match the platform and integrations actually used.
Common questions
Who signs off the automation checklist?
Use named owners for the decision, channel, data, product, service, content, accessibility, requirements, delivery, security, analytics, finance, and incident path as relevant.
Does a vendor checklist replace this review?
No. Vendor controls are inputs. The sender still needs evidence for the complete audience, journey, message, destination, operations, measurement, and recovery path.
How often should the checklist be rerun?
Rerun at least annually, and immediately after any material change, incident, complaint pattern, provider requirement, or unexplained outcome shift.
