HubSpot workflow enrollment triggers are usually understood as a one-time setup step: pick the criteria, save, done. The default behaviour behind that setup step is the part that catches teams out later, because it is the opposite of what most people assume. A contact who exits a workflow and later meets the same criteria again does not automatically re-enter, and a separate setting most teams add for a different reason can silently block re-entry altogether.
HubSpot Workflow Enrollment Triggers: The Default Nobody Expects
HubSpot’s own documentation on setting workflow enrollment triggers states the default plainly: “by default, records are only enrolled in workflows the first time they meet the workflow enrollment triggers or are enrolled manually.” Not periodically, not every time the criteria happens to be true again, once. A contact who meets a workflow’s criteria, gets enrolled, later stops meeting it, and then meets it again months later does not re-enter on their own. The workflow has already done its one enrollment and, by default, considers that contact finished with it.
This is not a bug, a plan limitation, or an edge case that only shows up in unusual configurations; it is the documented default across HubSpot’s enrollment trigger types: filter-based triggers, where a property or combination of properties needs to evaluate true, event-based triggers, where a specific event such as a form submission needs to occur, webhook-based triggers on Data Hub Professional or Enterprise, and schedule-based triggers tied to a fixed calendar date or a date property. The one type that does not follow this pattern is a schedule-based trigger, since HubSpot’s own documentation on schedule-based enrollment triggers confirms a workflow can be set to “recur just once, or on an annual, monthly, weekly, or daily schedule” by design, not by accident; everything else fires once per record unless re-enrollment is separately configured. Per that same enrollment triggers documentation, up to 250 filters can be added to a single workflow’s enrollment triggers, which is plenty of room to build a genuinely precise one-time enrollment condition, and none of that precision changes the fact that it only fires once per record unless something else is configured to change that.
Re-Enrollment Has to Be Configured, Not Assumed
The setting that changes the default lives in the same place enrollment triggers are edited, on its own dedicated tab next to the enrollment criteria (the Re-enrollment tab for a contact-based workflow, Settings for other object types), and HubSpot’s own documentation is direct that it is opt-in: “set up your re-enrollment settings in your workflow to enroll records in a workflow again.” Nothing about adding more filters to the original enrollment trigger turns re-enrollment on; re-enrollment is a distinct configuration step, not a side effect of a stricter or more specific enrollment condition.
For event-based triggers specifically, HubSpot’s documentation adds a further choice once re-enrollment is being configured at all: “you can enroll the object only once or each time the event occurs.” That is a genuine decision, not a default to accept blindly. A workflow triggered off a form submission that should fire fresh automation every single time someone fills that form in needs “each time the event occurs” selected explicitly; left on the default of once only, the second and every subsequent submission from the same contact does nothing, silently, with no error anywhere to flag it.
The Unenrollment Trap: One Setting, Two Effects
A contact-based workflow offers three ways to unenroll someone: they no longer meet the enrollment criteria, they hit the workflow’s goal, or they are added to a suppression segment. The suppression segment option is the one most likely to surprise a team, because per HubSpot’s own documentation on setting unenrollment triggers, adding a suppression segment does more than remove a currently-enrolled contact: “the contact will not be enrolled in the workflow even if they meet the enrollment triggers at a later time,” and while a contact is a member of that segment, “the contact cannot be manually enrolled” either. A suppression segment is not just an exit condition, it is also a standing block on both automatic and manual enrollment for as long as membership lasts.
That second effect is easy to miss because a suppression segment is usually built and named around removing people, a Do Not Contact list or an unsubscribed segment, not around the fact that the same list also gates future entry to every workflow it is attached to. A contact who is genuinely unsubscribed and later resubscribes is the case this is meant to handle correctly, and HubSpot’s own documentation confirms it does: once removed from the segment, “those contacts won’t automatically enroll in the workflow, even if they meet the workflow’s enrollment triggers. They’ll only be eligible to enroll the next time they meet the workflow’s enrollment or re-enrollment criteria.” Leaving a suppression segment does not retroactively re-enroll anyone; it only clears the block for the next time the enrollment or re-enrollment criteria is actually met again.
Working through a concrete case makes the interaction easier to spot before it causes a problem. A nurture workflow enrolls contacts when a specific product-interest form is submitted, and the same workflow also has a suppression segment attached for contacts who have opted out of marketing email, for the sensible reason that they should never receive that nurture sequence. A contact who opted out before ever submitting that form, and so was never enrolled in the first place, later opts back in and submits it for the first time. Nothing happens the moment they leave the suppression segment; nothing happens until they actually meet the enrollment criteria, which for this contact means genuinely filling the form in, not simply being removed from the list. The trap is not that the block is permanent, it is that removing someone from a suppression segment feels like it should be the re-enrollment event on its own, and per HubSpot’s own documentation it is not: it only restores eligibility for the next genuine match against the enrollment or re-enrollment criteria, and for a contact who has already been through the workflow once, that means the re-enrollment criteria specifically, not the original enrollment trigger a second time.
Where Teams Get This Wrong
The most common mistake is assuming enrollment criteria alone determines who is in a workflow at any given moment, the way a live filter or a static list segment does. It does not. Enrollment triggers decide who gets added and when; whether a record is added more than once is a completely separate decision, made in the re-enrollment settings, that has to be configured deliberately rather than inferred from how carefully the enrollment criteria itself was written.
The second common mistake is adding a suppression segment to a workflow without checking whether re-enrollment is meant to still work for people who leave that segment. Because a suppression segment blocks both automatic and manual enrollment for as long as membership lasts, a workflow that expects a contact to re-enter once they leave the segment needs its enrollment and re-enrollment criteria checked against that expectation, not assumed to keep working because re-enrollment was configured correctly before the suppression segment was added.
The third common mistake is leaving an event-based trigger’s re-enrollment choice on its default rather than deciding “once” versus “each time the event occurs” deliberately. A workflow meant to fire fresh automation on every form submission from the same contact, left on the once-only default, will look like it stopped working after the first submission, when it is actually working exactly as configured.
The fourth common mistake is treating a workflow’s enrollment behaviour as self-evident from reading its filters, without separately checking the tabs where re-enrollment and unenrollment actually live, Re-enrollment and Settings for a contact-based workflow. A workflow can have a perfectly sensible-looking set of enrollment filters and still behave unexpectedly, because the filters were never the part of the configuration controlling repeat enrollment in the first place.
The fifth common mistake is testing a workflow’s re-enrollment behaviour by manually re-enrolling a test record and checking it goes through, then assuming the automatic path will behave the same way. It will not necessarily. HubSpot’s own documentation on re-enrollment triggers is direct that “records that are manually re-enrolled do not have to meet the initial enrollment triggers or re-enrollment triggers to enroll,” so a successful manual re-enrollment only confirms re-enrollment is switched on for the workflow at all, not that the specific trigger a real contact needs to hit automatically actually fires correctly. A workflow that looks correctly configured because a tester kept manually re-adding themselves can still fail to re-enroll a real contact automatically, for exactly the trigger-level reason the manual test never exercised.
Related Reading
For the CRM build work that puts workflow configuration into practice, see HubSpot Consultancy. For the automation layer this often sits alongside, see n8n Consultancy. For the strategy layer above any single workflow, see RevOps Consultancy.
Go deeper: HubSpot Lifecycle Management: Contacts vs Custom Objects · Automated Pipeline Hygiene · HubSpot Deal Stage Hard Stops for CRM Governance
Frequently Asked Questions
Does a contact automatically re-enter a HubSpot workflow if they meet the criteria again?
No. HubSpot’s own documentation is explicit that records are only enrolled the first time they meet the criteria, or through manual enrollment, unless re-enrollment settings are configured separately. Meeting the same criteria a second time does nothing on its own.
Does leaving a suppression segment automatically re-enroll a contact in the workflow?
No. HubSpot’s own documentation is explicit that contacts removed from a suppression segment “won’t automatically enroll in the workflow, even if they meet the workflow’s enrollment triggers.” They only become eligible again the next time they genuinely meet the enrollment or re-enrollment criteria, not simply by leaving the segment.
Why did a workflow stop triggering after the first form submission from the same contact?
Because event-based enrollment triggers default to enrolling a record only once for that event, per HubSpot’s own documentation. Firing on every submission from the same contact needs the “each time the event occurs” option selected explicitly in the re-enrollment settings, not left on the default.
Does a suppression segment only affect contacts currently in a workflow?
No. HubSpot’s own documentation states that a contact who is a member of a suppression segment “cannot be manually enrolled” and will not be enrolled automatically either, even if they meet the enrollment triggers. The block applies to both paths for as long as the contact stays a member of that segment.