What's the difference between enrollment criteria and goal criteria in HubSpot workflows?

Enrollment criteria decide who enters the workflow — evaluated when the trigger fires (property change, form submission, list membership). Goal criteria decide who exits early — evaluated continuously while the contact is enrolled, and on enrollment. The crucial detail: if goal criteria are already true at the moment of enrollment, HubSpot considers the contact to have already achieved the goal and completes the workflow immediately without running any actions. This is the #1 cause of 'workflow is on, contacts are enrolling, but actions aren't running' — the contact enters and exits in the same instant. To diagnose, temporarily change goal criteria to something impossible (e.g., 'is private demo lead' = true when no contact has that flag) and re-test; if actions fire, goal evaluation was the issue.

Why does the same contact only enroll once in a HubSpot workflow even when they match the criteria again later?

Re-enrollment is disabled by default in all new HubSpot workflows. Even if a contact matches the enrollment criteria on day 1, leaves the criteria on day 5, and re-matches on day 30, HubSpot won't re-enroll them. To enable: Workflow Settings → Re-enrollment → toggle ON, THEN explicitly select which of the enrollment triggers should re-enroll. The toggle being ON with no triggers selected does nothing — HubSpot requires both actions. The UI doesn't validate this for you, so it's easy to miss. After enabling, contacts who currently match but are 'completed' from a prior run will re-enroll on the next property change matching the selected triggers, not retroactively.

Can I see why a specific contact didn't enroll in a HubSpot workflow?

Yes — and this is the single highest-leverage diagnostic in HubSpot. Inside the workflow editor, click 'Test' (top right) → enter the contact ID or email. HubSpot evaluates every enrollment criterion against the contact's current data and shows a green check or red X for each one, with the actual property value next to it. Suppression-list hits also show up. For historical enrollment attempts on a contact who SHOULD have enrolled but didn't, open the contact record → Workflows tab → expand the workflow in question. 'No enrollment history' = criteria never matched (or were never evaluated because the trigger pipeline missed the change). 'Suppressed' = on a suppression list. 'Completed' = enrolled and completed (possibly instantly via goal).

Why does my HubSpot contact-based workflow not fire when an associated company property changes?

Architectural separation: contact-based workflows can READ associated-company properties in their criteria but cannot TRIGGER on company property changes. The change-tracking pipeline that fires workflow enrollment is scoped to the contact object — company-property changes don't propagate to contact-based workflows. To trigger contact workflows from company changes, build a two-step setup: (1) a company-based workflow that fires on the company property change and updates a property on all associated contacts (e.g., copies `company.tier` to `contact.account_tier`); (2) a contact-based workflow that triggers on the change to `contact.account_tier`. It's an extra workflow, but it's the only way to bridge the object boundary.

Do paused HubSpot workflows still evaluate enrollment criteria?

No — and there's an important sub-detail. A paused (toggled Off) workflow stops evaluating new enrollments entirely. Contacts who would have matched while it was off don't enroll retroactively when you turn it back on. Additionally, contacts who were ENROLLED when you paused (mid-flow, waiting on a delay) stay frozen — their delay timer pauses too. When you re-enable the workflow, those mid-flow contacts resume from where they paused, and any delay timers that 'should have' completed during the pause fire immediately. Practical effect: pausing a workflow for 3 days and turning it back on can produce a burst of delayed actions (emails, internal notifications) firing in the first few minutes after re-enable. Tell stakeholders before flipping the toggle.

How do I debug a HubSpot workflow that says 'Enrolled' but no actions ran?

This is almost always goal criteria firing immediately. The flow: open the contact record → Workflows tab → click the workflow. If the history shows 'Enrolled in workflow' immediately followed by 'Completed workflow' with no actions in between, goal criteria were true when the contact enrolled. Test it: in the workflow editor → Settings → Goal section. Either tighten enrollment criteria so contacts who already meet the goal can't enroll, or remove the goal criteria entirely if it doesn't add value (you can always achieve the same effect with an If/Then branch inside the workflow). Less common cause: a Delay action set to 'Delay until' a calendar date in the past — HubSpot skips the delay but logs it differently. Check the workflow definition for any Delay actions referencing past dates.

Why do API-triggered property changes not always trigger HubSpot workflows?

Two reasons. First: the API call may have `skip_property_tracking=true` set, which writes the property but bypasses the change-tracking that fires workflow enrollments. Common in bulk imports and in older Zapier zaps that use the v1 API. Fix: omit the parameter or set it to false. Second: HubSpot's change-tracking pipeline can lag by 5–10 minutes during peak ingestion windows — if your test is 'change the property, immediately check enrollment', you might be looking before the pipeline caught up. Wait 15 minutes and re-check. For the broader pattern of 'why isn't this workflow firing for any contact', check Operations Hub → Workflows → Workflow Performance for enrollment counts over the last 24 hours. A workflow that should be firing dozens of times per day but shows 0 enrollments is the symptom of a broken pipeline, not a broken criterion.

Fix Guide

How to Fix HubSpot Workflows That Aren't Triggering

Step-by-step fix guide with AI-powered diagnosis from BuildForce.

A HubSpot workflow that's 'On' but never enrolling contacts almost always falls into one of five buckets. (1) 'Is known' on a calculated property — HubSpot treats a calculated property returning 0 or empty as 'unknown' even if the calc ran cleanly. (2) Re-enrollment is disabled (the default) and the contact has previously been through the workflow once. (3) Goal criteria are already true at enrollment time, so HubSpot completes the workflow immediately without running any actions — looks identical to 'not firing'. (4) A suppression list silently blocks enrollment with no trace in workflow history. (5) The trigger property was updated by a path that skips change-tracking (some Operations Hub flows, certain bulk imports, API calls with `skip_property_tracking=true`). The diagnostic flow that resolves 90% of cases: in the workflow editor, click 'Test' → enter the contact ID → HubSpot evaluates every criterion and shows pass/fail. If Test passes but production doesn't enroll, the failure is suppression list or change-tracking; if Test fails, it's the criteria themselves.

Enrollment Trigger EvaluationRe-enrollment ToggleSuppression BlockGoal Criteria

Get AI-Powered Diagnosis See Pricing

The HubSpot workflow 'not firing' problem is rarely a bug in HubSpot — it's almost always a semantics mismatch between what the workflow builder thinks 'is known' means and what HubSpot actually evaluates. The cleanest diagnostic is the built-in Test Contact tool inside the workflow editor: it shows every criterion's evaluation against the real contact data, and the failure shows up immediately. Most teams skip this step and instead build elaborate logging in their integration to figure out what changed.

Re-enrollment is the second-most common gotcha. Marketing automation teams expect 'sent welcome email' to fire every time a new lead converts. HubSpot's default behavior is: each contact enrolls in a workflow exactly once, ever. To re-enroll on the same trigger, you have to (a) turn ON the Re-enrollment toggle in workflow settings AND (b) explicitly select which triggers re-enroll. Doing only (a) does nothing — the toggle ON with no selected triggers means 'no re-enrollment'. The UI doesn't warn you about this.

Goal criteria firing immediately is the most confusing failure mode because the workflow history shows 'Enrolled' and then 'Completed' with no actions in between. This means the goal criteria were already true when enrollment happened. HubSpot considers the contact to have already achieved the workflow's purpose, so it completes without running actions. Common case: a workflow with goal criteria 'lifecyclestage = customer' enrolling a contact who's already a customer. The fix is either to tighten the enrollment criteria (don't enroll customers) or remove the goal criteria entirely.

HubSpot evaluates workflow enrollment in near-real-time for property-change triggers (typically <5 seconds) but every 15 minutes for filter-based triggers ('contacts where X is true'). Re-enrollment is OFF by default for all new workflows as of HubSpot's 2023 platform changes. A workflow with 'Enrolled in workflow' as a trigger fires within 30 seconds of the upstream enrollment.

Source: HubSpot Knowledge Base — Workflow Enrollment Behavior

Symptoms

Workflow status is 'On' but no contacts have enrolled in days

A specific contact meets the criteria visually but isn't enrolled

Workflow history shows 'criteria not met' for contacts that clearly should match

Contact enrolled once, criteria reset, then never re-enrolled despite matching again

Workflow shows enrolled contacts but the first action never fires

Test contact succeeds but production contacts don't enroll

Root Causes

Re-enrollment toggle disabled

By default, HubSpot enrolls a contact in a workflow once — even if they later leave and re-match the criteria. The Re-enrollment toggle in the workflow settings must be ON, and you must select which triggers re-enroll (re-enrollment uses a separate trigger list from initial enrollment).

'Is known' check on a calculated property

HubSpot treats calculated properties differently than user-set properties for the 'is known' operator. A calculated property that returns 0 or an empty string is 'unknown' even if the calculation ran. Use 'is greater than 0' or 'is not equal to empty' instead.

Suppression list catching the contact

If the workflow has a suppression list (unsubscribe list, internal employees, etc.) and the contact is on any one of them, enrollment is silently blocked. The workflow history shows no enrollment attempt at all.

Goal criteria already satisfied at enrollment time

When goal criteria match at the moment of enrollment, HubSpot completes the workflow immediately without running any actions. This is by design — the contact already 'achieved the goal' before enrollment — but it looks like the workflow isn't firing.

Trigger property updated outside the watched action

Enrollment triggers fire when a property changes. If the property is updated via an API call that doesn't increment the change-tracking timestamp (e.g., bulk imports with skip_property_tracking=true), the workflow doesn't see the change and doesn't enroll.

How to Fix It — Step by Step

Use Test Contact to validate enrollment evaluation

In the workflow editor, click 'Test' → enter a contact ID. HubSpot evaluates every enrollment criterion against that contact and shows you exactly which criteria pass and fail. This is the fastest single tool for diagnosing 'this contact should enroll but doesn't'.

Check the workflow history for the contact

Open the contact record → Workflows tab. It shows enrollment attempts, suppressions, and completed runs. If the contact has no history entry for this workflow at all, the enrollment criteria never matched. If there's a 'completed without actions' entry, goal criteria fired immediately.

Enable re-enrollment with the right triggers

In workflow settings → Re-enrollment → toggle ON. Then explicitly select which enrollment triggers should re-enroll a contact. HubSpot defaults to no triggers selected even when re-enrollment is on — so the toggle alone doesn't do anything until you pick triggers.

Replace 'is known' with explicit checks for calculated properties

For calculated properties (hubspotscore, lead_score__c, custom calc properties), change 'is known' to 'is greater than 0' or 'is not equal to' a specific default value. This is the single most common workflow-not-firing root cause for marketing automation orgs.

Audit suppression lists

Open the workflow → Settings → Suppression. Review every suppression list and confirm the test contact is not on any of them. If you're using a global suppression list (e.g., 'Internal employees'), confirm it's actually meant to apply to this workflow.

Check goal criteria evaluation

If the workflow has a goal, switch the workflow off briefly and modify the goal criteria to be impossible to satisfy at enrollment (e.g., 'lifecyclestage = customer' when test contacts are leads). Re-test enrollment. If the contact now enrolls and runs actions, the goal was firing immediately on enroll.

Verify trigger property change is observable

For property-change triggers, manually update the property via the HubSpot UI on the test contact. If the workflow enrolls, the change-tracking pipeline works. If it doesn't, the property update path (often a Zapier or Operations Hub flow) is bypassing change tracking.

Real-world incidents we've seen

A B2B SaaS marketing team whose lead-scoring workflow stopped firing after they migrated from a manual 'lead_score' number property to a HubSpot calculated property. The criteria still said 'lead_score is known'; the calc returned 0 for ~40% of contacts (those without scoring signals); HubSpot treats 0-result calc properties as unknown. Fix: change criteria from 'is known' to 'is greater than or equal to 0'. 28,000 contacts caught up in a 24-hour enrollment burst.
A growth team's nurture workflow set up six months prior 'stopped working' for known leads — turned out re-enrollment had been disabled from day one. The original setup matched 100% of leads on the first day; on day 2+, every new lead matched the criteria but had already been enrolled by an unrelated test before launch. Fix: enable re-enrollment, select the trigger property, manually re-enroll the affected contacts via a workflow targeting them with 'enrolled in nurture' = false.
A consulting team that built a customer-success workflow with goal criteria 'health_score > 80' to exit happy customers — but the workflow was enrolling brand-new customers whose initial health score defaulted to 95. Every enrollment completed instantly because goal criteria were true at enrollment time. Fix: removed the default health-score value so new customers enter with null, change goal to 'health_score > 80 AND health_score is known', re-enroll affected contacts.