Workflow QA Checklist

Most automation failures aren’t caused by a wrong action. They come from the wrong people entering, the right people being skipped, or two workflows fighting over the same field. This checklist walks through what to test before an automation goes live and what to watch in the first two weeks after. It works for HubSpot workflows, Klaviyo flows, ActiveCampaign automations, Zoho workflow rules and integration-platform scenarios.

Print or save as PDF

How to use this checklist

Run it once per automation, before turning it on. Have the requirement in front of you (if there isn’t one, the CRM automation requirements template takes about twenty minutes to fill in). Each check should be answered with evidence: a test record ID, a screenshot of the setting, an enrollment count.

Ideally the person who built the automation isn’t the only person who tests it. Builders test the path they designed. A second person tends to try the paths the builder never pictured.

For platform-specific settings, use the HubSpot workflow checklist or the Klaviyo flow checklist alongside this one.

1. Record the basics

• Automation name: following your naming convention.
• Platform and object: where it runs and what it enrolls (contacts, deals, profiles, orders).
• Owner: the person accountable once it’s live.
• Requirement reference: link to the spec.
• Tester and date.
• Planned go-live date.

2. Naming and documentation

1. The name says what it does and for whom, for example “Lead | Demo request | Assign + notify”.
2. The description or notes field explains the purpose and links to the requirement.
3. It sits in the right folder and has an owner recorded.
4. Any properties it creates or updates are in the data dictionary.

3. Trigger and enrollment

1. The trigger matches the requirement exactly (event, property change, list or segment membership, date, form, webhook).
2. If the trigger is a property change, it fires on the change you intend, not on any update to that property.
3. Create a test record that should enroll. Confirm it enrolls.
4. Create a test record that is close but should not enroll (wrong region, existing customer, missing consent). Confirm it doesn’t.
5. Check whether existing records that already meet the criteria will enroll when the automation is turned on, and whether that’s wanted.
6. Re-entry behavior matches the requirement: once ever, once per event, or again after leaving.
7. Estimate expected enrollment volume per day or week and write it down. You’ll compare against it after launch.

4. Exclusions and suppressions

1. Unsubscribed and bounced contacts are excluded from any marketing message steps.
2. Existing customers are excluded from acquisition messaging if that’s the intent.
3. Contacts with an open deal or active sales sequence are excluded from conflicting nurture.
4. Internal staff, test records and competitor domains are excluded.
5. Records that hit the goal or exit condition are removed, and you’ve tested that with a record.
6. Contacts in another automation with overlapping messaging are identified, and the overlap is handled (suppression, priority rule or merged flows).

5. Conditions and branches

1. Every branch has at least one test record that goes down it.
2. The fallback or “everyone else” branch does something sensible, not nothing by accident.
3. Branch conditions are evaluated at the right moment. A branch checked immediately may see data that hasn’t synced yet.
4. Blank values are handled. Test a record where the branching property is empty.
5. Branch order is correct where the first matching branch wins.

6. Timing and delays

1. Delays use the right unit (minutes, hours, days, business days).
2. Date-based delays use the correct date property and time zone.
3. Send-time restrictions (business hours, quiet hours, weekday only) are set where needed.
4. Delays waiting for an event have a timeout and a defined path if the event never happens.
5. The total length of the automation is written down, and you’ve checked what happens if a record’s situation changes halfway through.

7. Actions and data updates

1. Every property update writes the exact value expected (check internal values for dropdowns).
2. No other automation overwrites the same property shortly after. Search for other automations that set it.
3. Owner assignment rules work for every branch, including when no rule matches.
4. Tasks are created with the right owner, due date and title.
5. Internal notifications go to the right people and contain enough context to act on (record link, key fields).
6. Webhooks or integration steps return success on a test record, and failures are logged somewhere someone looks.
7. Records are associated or created on the right objects (deal linked to contact and company, for example).

8. Messages

1. Each email or SMS has been sent as a test and checked on mobile and desktop.
2. Personalization tokens have fallbacks, and you’ve tested a record with blank values.
3. Links work and carry the right tracking parameters.
4. Sender name, from address and reply-to are correct, and replies go to a monitored inbox.
5. The unsubscribe link and footer are present on marketing messages.
6. Discount codes or offers are valid for the period the automation runs.
7. Message content still makes sense if someone receives it late (after a long delay or a re-entry).

9. Reporting

1. Success is measurable: the goal, conversion event or property you’ll check is defined.
2. Any campaign, UTM or source value is set so results can be attributed.
3. A list, segment or view exists to see who is currently enrolled.

10. Go-live

1. Test records have been removed from the automation and deleted or marked as test.
2. The decision about enrolling existing records has been made deliberately.
3. The owner knows it’s live and where to look for errors.
4. Any automation this one replaces has been turned off at the same time, with remaining enrollees handled.

11. Post-launch monitoring

1. Day 1: enrollment count is within the expected range. Open three real enrolled records and follow their path.
2. Day 1: action or error logs show no repeated failures.
3. Day 3: messages are sending and engagement isn’t abnormally low (a sign of deliverability or targeting problems).
4. Day 7: check for complaints from sales or customers about duplicate or wrong messages.
5. Day 14: compare outcome against the requirement’s expected result. Note anything to change.
6. Schedule a review in 90 days, then add it to the regular automation review cycle.

Sign-off

• All checks passed or exceptions noted: yes or no.
• Exceptions and accepted risks: list them.
• Approved by: name, role, date.