HubSpot Workflow Checklist

This checklist covers the HubSpot-specific settings that most often cause workflow problems: the wrong trigger type, re-enrollment switched on (or off) by accident, a missing suppression segment, or two workflows setting the same property. Use it when building a new workflow or reviewing an existing one. It pairs with the platform-neutral workflow QA checklist, which covers testing and monitoring in more general terms.

Print or save as PDF

How to use this checklist

Work through it in the order HubSpot’s editor presents things: workflow type and object, enrollment trigger, trigger settings, actions, then the workflow’s own settings. Setting names below follow HubSpot’s current workflow editor. HubSpot updates its interface often, and some options depend on your subscription tier, so if a label looks slightly different in your portal, go by what the setting does.

One terminology note before you start. HubSpot now calls lists segments. Older documentation, internal notes and workflow names may still say “list”, but suppression and membership triggers use segments.

1. Workflow type and setup

1. The workflow is based on the right object. Contact-based workflows can’t directly act on deals in the same way deal-based workflows can, and some settings (goals, merged-record enrollment, unenrolling from other workflows) are only available on contact-based workflows.
2. The name follows your convention and makes the purpose clear without opening it, for example “Contact | Demo request | Assign owner”.
3. The workflow is saved in the correct folder.
4. A description explains the purpose and links to the requirement.
5. You’ve searched existing workflows for one that already does this. Duplicates are common in older portals.

2. Enrollment triggers

First, a quick reference for the trigger types:

• When an event occurs: for things that happen at a moment (form submitted, property value changed, page viewed, email clicked).
• When filter criteria is met: for states (lifecycle stage is X and country is Y). Filter criteria can also check that something has not happened, which event triggers can’t.
• Based on a schedule: for recurring runs (daily, weekly, monthly or a specific date).
• Webhook triggers: where your subscription includes them, for events sent from external apps.
• Manual: when the workflow should only run when someone enrolls records deliberately.

Then check:

1. The trigger type matches the requirement, using the reference above.
2. For a property-change trigger, you’ve confirmed the exact value change that should enroll, not “any change” unless that’s intended.
3. For filter criteria, AND/OR groups are built correctly. Read them aloud as a sentence and check it says what you mean.
4. Filters don’t depend on a property that is often blank when the record is first created (for example an enrichment field that fills in later).
5. Segment-based triggers point to the right segment, and you know whether that segment is active (dynamic) or static (fixed membership).
6. If the trigger relies on a form, you’ve listed every form that should count, including forms on other pages or pop-ups.

3. Re-enrollment

1. You’ve opened the trigger’s Settings tab and checked Re-enroll. By default, a record only enrolls the first time it meets the triggers.
2. For event triggers, you’ve chosen whether records should enroll only once or each time the event occurs.
3. For filter criteria triggers, re-enrollment is tied to the specific criteria that should cause it. A workflow that should run every time a contact requests a demo needs re-enrollment configured on that trigger.
4. If re-enrollment is on, the actions are safe to repeat. Check for duplicate tasks, repeated emails and counters that increment twice.
5. If re-enrollment is off, you’ve confirmed no legitimate repeat case will be missed (a second demo request six months later, a returning customer).
6. For contact-based workflows, you’ve decided whether Automatically enroll merged records should be on. Merged contacts don’t enroll by default.

4. Unenrollment and suppression

1. Unenrollment conditions are set in the trigger’s Settings tab under the “Unenroll if…” options.
2. For contact-based workflows, you’ve decided whether contacts who no longer meet the enrollment criteria should be removed. This matters for long nurtures: if someone becomes a customer halfway through, should the rest still send?
3. Suppression segments are added for groups that should never be enrolled or should be removed: existing customers, open-deal contacts, employees, competitors, test records.
4. Suppression segments are themselves correct. Open each one and spot-check membership.
5. For non-contact workflows (company, deal, ticket), exclusion or unenrollment triggers are set to cover the same cases.
6. Under the workflow’s Connections settings (contact-based only), you’ve decided whether enrolling here should unenroll contacts from other workflows, and if so, from which specific workflows rather than all of them.

5. Goals

1. For contact-based workflows with a clear success event (meeting booked, deal created, became a customer), a goal is set.
2. Goal criteria are a property or segment condition that the contact will actually meet when they convert. Test it with a record.
3. You understand that contacts who meet the goal are unenrolled, so later steps won’t run for them. Make sure nothing after the goal point is required for converted contacts (such as a handoff task).
4. Workflows without a natural goal use unenrollment criteria or an end branch instead.

6. Branches and delays

1. Each if/then branch has a sensible “None met” path. Leaving it empty means records quietly end there.
2. Branches that check a value set earlier in the same workflow come after a short delay if that value comes from a sync or enrichment that may not be instant.
3. Branch criteria handle blank values deliberately.
4. Random split branches (for A/B tests) have a defined end date and success measure.
5. Delays use the right type: a set amount of time, until a specific date or date property, or until an event happens. “Delay until event” steps have a maximum wait and a path for records that time out.
6. Date-based delays use the correct date property and account for the account’s time zone.

7. Actions

1. Set property value actions write exact dropdown internal values.
2. Search other workflows for actions that set the same property. If two workflows write it, document which should win.
3. If the workflow changes lifecycle stage, it follows your lifecycle map and doesn’t set a stage lower than the current one unless that backward move is deliberate and tested.
4. Rotate record to owner or owner-setting actions use current team members and have a fallback.
5. Create task actions have the right owner, due date, priority and a title that says what to do.
6. Send internal email notification or in-app notifications go to roles that will act, with record links and key fields in the body.
7. Send email actions use marketing emails that are ready for automation, with the right subscription type.
8. You know that marketing emails only go to contacts who can receive them: marketing contacts with the right subscription status. Non-marketing contacts and unsubscribed contacts won’t receive them.
9. Enroll in another workflow actions point to the right workflow, and that workflow’s own enrollment rules won’t block the record.
10. Webhook or custom code actions (where available on your tier) have been tested and failures are visible to someone.

8. Workflow settings

1. Under Timing, Run actions at specific times only is set if messages or tasks should only happen in business hours or on weekdays.
2. Don’t run actions on specific dates covers public holidays where needed. These can repeat annually.
3. Schedule workflow to turn off automatically is set for time-limited campaigns.
4. Under Performance, notifications are turned on so the owner hears about issues that need review or unusual changes in enrollment rate.
5. The account time zone is correct, since timing settings rely on it.

9. Testing

1. You’ve used the workflow’s test option with a real or test record to follow the path before turning it on.
2. A test record has gone down every branch.
3. A record that should be suppressed has been confirmed as not enrolling.
4. Emails have been reviewed as test sends, with personalization tokens checked against a record that has blank values.
5. When turning on, you’ve chosen deliberately whether to enroll existing records that already meet the criteria. This choice can’t be undone for records already enrolled.

10. After launch

1. Day 1: check the enrollment history to confirm the number enrolled is close to what you expected.
2. Day 1: check the action logs for errors or skipped actions, and the reasons given.
3. Week 1: open three enrolled records and check their timeline matches the workflow’s path.
4. Week 2: review performance against the goal or success measure.
5. Add the workflow to your quarterly workflow review, with its owner.

Quarterly HubSpot workflow review

1. Export the workflow list and sort by last enrollment date. Investigate any active workflow with no enrollments in 90 days.
2. List workflows with no owner or description.
3. Identify properties set by more than one workflow.
4. Check that users referenced in rotate, task and notification actions are still active.
5. Confirm suppression segments still reflect current customers, staff and test records.
6. Check marketing emails used in workflows for outdated offers, dates and links.

For background on the decisions behind this checklist, see the HubSpot workflow audit guide and HubSpot lifecycle stages.