Why a Contact Can Suddenly Leave a HubSpot Workflow
This can be confusing because the original enrollment may have worked exactly as expected. You can confirm that the contact entered the nurture sequence, completed one or more actions, or reached a delay, only to find that the contact is no longer active in the workflow.
Successful enrollment does not guarantee that a contact will remain enrolled until the final action. In contact-based workflows, HubSpot provides a Connections setting that allows one workflow to remove a newly enrolled contact from other workflows.
The important detail is which event actually triggers the removal. The trigger is not a property update inside the original workflow, reaching a certain action, or simply being active in two workflows. The removal happens when the contact enrolls in the workflow that has the Connections rule enabled.
For example, suppose a contact is already active in Workflow A. Ten minutes later, the same contact qualifies for Workflow B. When HubSpot enrolls the contact in Workflow B, it checks Workflow B's Connections settings. If Workflow B is configured to remove contacts from Workflow A, the contact is unenrolled from Workflow A at that enrollment moment.
If Workflow B has no Connections removal rule, the contact can remain enrolled in both workflows.
Workflow Conflict Example
| Situation | Workflow A | Workflow B | What Happens |
|---|---|---|---|
| Contact is already in Workflow A and later enters Workflow B | Active | No Connections rule | Contact can remain active in both workflows |
| Contact is already in Workflow A and later enters Workflow B | Active | Unenroll from all other workflows enabled | Contact is removed from Workflow A when enrollment in Workflow B occurs |
| Contact is already in Workflow A and later enters Workflow B | Active | Unenroll from specific workflows with Workflow A selected | Contact is removed from Workflow A when enrollment in Workflow B occurs |
| Contact is already in Workflow A and later enters Workflow B | Active | Unenroll from specific workflows, but Workflow A is not selected | Contact remains in Workflow A and also enters Workflow B |
| Contact enters Workflow B first and Workflow A much later | Not yet enrolled | Connections rule exists in Workflow B | Workflow B does not later remove the contact merely because they subsequently enter Workflow A |
The last example is especially important. The Connections setting works at the time of enrollment into the workflow where that setting is configured. It does not remain active as a permanent rule that continuously scans the contact's future workflow memberships.
How to Confirm Another Workflow Removed the Contact
Before changing enrollment filters or rebuilding actions, review the workflow history and establish when the contact was unenrolled.
In your HubSpot account, go to Automation > Workflows. Depending on your account navigation, you may first need to click More.
Open the workflow that unexpectedly lost the contact.
Review the workflow's Enrollment history or Action logs and search for the affected contact.
Note the date and time around the unenrollment event.
Review that contact's activity in other relevant workflows and look for another workflow enrollment occurring at approximately the same time.
The timestamp comparison is particularly useful for a Connections conflict. If the contact was removed from Workflow A at 10:42 AM and enrolled in Workflow B at 10:42 AM, inspect Workflow B's Connections settings.
If the contact entered Workflow B hours or days before the unexplained removal from Workflow A, the Connections rule in Workflow B is unlikely to explain that later event because the rule applies when enrollment into Workflow B occurs.
Check “Unenroll Contacts From Other Workflows”
Once you identify the workflow that may be causing the conflict, open that workflow and inspect its Connections configuration.
Go to Automation > Workflows and open the competing workflow.
In the upper-left area of the workflow editor, click Settings.
In the right panel, find the Connections section.
Look for Unenroll contacts from other workflows when enrolled in this workflow.
This wording tells you exactly when the rule executes: when the contact is enrolled in this workflow.
If the switch is enabled, HubSpot provides two choices:
Unenroll from all other workflows: At the moment the contact enrolls in this workflow, HubSpot removes the contact from all other workflows in which the contact is currently enrolled.
Unenroll from specific workflows: At the moment the contact enrolls in this workflow, HubSpot removes the contact only from the workflows selected in this setting.
For example, imagine Workflow B is configured to Unenroll from specific workflows, with Workflow A selected. A contact can spend several days progressing normally through Workflow A. Nothing happens merely because Workflow B exists. But the moment that contact qualifies for and enrolls in Workflow B, HubSpot removes it from Workflow A.
The distinction between All and Specific matters. The first option can affect every other workflow in which the contact is active, while the second lets you define exactly which workflows should give way when the new enrollment occurs.
Also remember that the Connections setting is available for contact-based workflows. If the contact was removed much later and there was no corresponding enrollment into another contact-based workflow at that time, continue checking the other unenrollment causes below.
Do Not Confuse This With a Suppression Segment
A Connections conflict and a suppression segment can both result in a contact being absent from a workflow, but they are different mechanisms.
If a contact is already a member of a workflow's suppression segment when enrollment is evaluated, HubSpot can prevent that contact from entering the workflow. A suppression segment can also remove a contact who is already enrolled if the contact becomes a member of that segment while the workflow is running.
If your history indicates that suppression is responsible, see our HubSpot Contact Not Enrolling? Check the Suppression List guide for the dedicated troubleshooting process.
A Connections issue is different because another contact-based workflow is controlling the removal. If the contact entered Workflow A normally and the unexplained unenrollment occurred at the same time it entered Workflow B, Workflow B's Connections configuration becomes a strong suspect.
Other Unenrollment Causes to Rule Out
If the Connections settings do not explain the removal, check the other supported ways HubSpot can unenroll a contact.
Suppression segment: A currently enrolled contact can be removed immediately if they become a member of a suppression segment attached to the workflow.
Workflow goal: In a contact-based workflow, a contact that meets the workflow's goal criteria can be automatically unenrolled before the next action executes.
No longer meets enrollment criteria: A contact-based workflow can be configured to unenroll contacts when they stop meeting the workflow's enrollment criteria. Depending on the workflow's settings and where the contact is in the automation, HubSpot can remove the contact while it is waiting in a delay or before the next action processes.
Merged records: When records are merged, records included in the merge can be automatically unenrolled from workflows.
Manual unenrollment: An authorized HubSpot user can manually remove an active contact from the workflow through the workflow details page or the contact's Workflow memberships controls.
Checking these causes before changing workflow architecture can prevent you from fixing the wrong setting.
How to Prevent It Happening Again
Once you identify the workflow responsible, avoid automatically switching off cross-workflow unenrollment without considering why it was enabled.
There are legitimate situations where one automation should replace another. A sales-qualified lead, for example, may need to leave a broad nurture workflow when entering a more specific sales process. Similarly, conflicting customer communications may need to be kept apart.
If cross-workflow removal is necessary but the current setting is too broad, consider changing Unenroll from all other workflows to Unenroll from specific workflows and selecting only the automations that genuinely should stop.
This gives you more control over overlapping workflows while allowing unrelated operational, tracking, or data-management automations to continue when appropriate.
How to Verify the Fix
After correcting the Connections configuration, use a controlled test rather than assuming the problem is solved.
Select an appropriate test contact.
Enroll that contact in Workflow A, the original workflow that was losing contacts.
Confirm that the contact is actively processing or waiting inside Workflow A.
Cause the same contact to qualify for Workflow B, the workflow whose Connections settings you changed.
Review the workflow histories immediately after enrollment into Workflow B.
Confirm that Workflow A now behaves according to your intended configuration.
If the contact is supposed to remain active in both workflows, verify that it does. If Workflow B is intentionally supposed to remove the contact from Workflow A, confirm that the removal occurs at the moment the contact enters Workflow B and only affects the workflows you intended.
If you need a previously removed contact to enter the original workflow again, that becomes a separate re-enrollment issue. See our HubSpot Contacts Not Re-Enrolling? Enable Re-Enrollment guide before assuming the original enrollment trigger will automatically accept the contact a second time. HubSpot generally requires the appropriate re-enrollment settings for records to enroll again through the same qualifying conditions.
Quick Diagnostic Checklist
Find the exact unenrollment timestamp in the original workflow.
Look for enrollment in another contact-based workflow at approximately the same time.
Open that second workflow's Settings and find the Connections section.
Check whether “Unenroll contacts from other workflows when enrolled in this workflow” is enabled.
Confirm whether “All” or “Specific” workflows are selected.
Check whether the original workflow appears in the selected specific workflows.
Narrow the setting to specific workflows when broad removal is unnecessary.
Check suppression, goals, enrollment-criteria changes, merges, and manual unenrollment if the timestamps do not support a Connections conflict.
Run a controlled test contact after making the change.
Review both workflow histories immediately after the second enrollment.
