Your first useful check
Start here.
Find the record's enrollment history and the expected event time. Check whether it never entered, immediately exited or reached a failed action. That distinction determines which settings deserve attention.
Is this the right guide?
Use this when the intended record does not enter a HubSpot workflow. If it enters but an email or update fails, investigate that action separately. Access depends on subscription and workflow permissions.
What you can check and who can help.
- You can start here
- You can inspect record history and test entry conditions if you have workflow permissions. Keep checks limited to an approved test record.
- Bring in the responsible specialist
- Ask the automation owner to change entry rules, repeat-entry settings or message actions. Do not activate a full historical audience as a test.
Tools and access you need
Workflow editor, enrollment and action history, record property history, and permission to run approved test records. Availability varies by subscription and permissions.
Before changing settings, keep a copy of the current configuration so you can restore it. Use approved test records and remove customer details from shared evidence.
Follow the steps.
Start at step 1. Each result tells you what to check next; you do not need to change every setting mentioned.
Find which stage failed
Start yourself with workflow permissions.
- Look here
- Open the affected workflow and the record's enrollment and action history. Confirm the workflow is switched on and uses the intended record type.
- Check this
- Did the record never enter, enter and immediately leave, or reach an action that failed? An unsent email can belong to the third case.
- What it means
- Changing who enters will not repair a failed action after entry. Broadening the entry rules could instead send messages to the wrong people.
- Next move
- Continue with entry checks only if the record did not enter as expected. For an action failure, inspect that action's error and requirements.
Test the complete entry conditions
Read-only test before any rule change.
- Look here
- In the workflow editor, use Help > Troubleshoot enrollment for supported filter types, or the supported record-testing tool. Select the expected record and time period.
- Check this
- Review every condition. AND means all linked conditions must match; OR means one alternative can be enough. Compare values at the expected entry time, not only today's values.
- What it means
- A contact can match the rules now but not have matched them when the form arrived. The current workflow may also differ from the version active then.
- Next move
- Record the exact condition or historical setting that prevented entry. Do not loosen unrelated conditions.
Check existing and returning records
Automation owner approves audience changes.
- Look here
- Inspect whether activation included existing eligible records and whether re-enrollment is enabled. Re-enrollment means letting a previously entered record enter again.
- Check this
- Was the record already eligible before activation? Had it entered previously? Does the intended repeat event qualify under the current settings?
- What it means
- Future-only activation and restricted repeat entry can explain a missing enrollment without a broken rule.
- Next move
- Agree whether historical or repeat entry is wanted. Test a small approved scope before including older contacts.
Check exclusions and late-arriving information
Specialist change: automation owner.
- Look here
- Inspect suppression, goals, exit rules and record-property history. Suppression means keeping specified records out or stopping them from receiving actions.
- Check this
- Was the contact excluded, did it meet an exit condition, or was a required value populated after the workflow evaluated it?
- What it means
- A blank country or source at evaluation can behave differently from a completed value later. A delay alone does not guarantee the contact belongs in the sequence.
- Next move
- Make required information and exit behaviour explicit. Test delayed information and excluded contacts separately.
Test who stays out as well as who enters
Automation owner releases; marketing reviews the audience.
- Look here
- Use approved test records against a safe copy or controlled scope. Review the audience affected by the proposed change before release.
- Check this
- Test an eligible new contact, an ineligible contact, a returning contact and a suppressed contact. Confirm the intended action completes, not just entry.
- What it means
- The workflow is not fixed if the right person enters but unwanted contacts receive messages too.
- Next move
- Release the smallest correction, keep the previous version and monitor the agreed cases. Never use bulk enrollment as a debugging shortcut.
Keep the useful evidence.
Use this table as a reference while following the steps. Keep the information that identifies where the journey failed; remove names and email addresses before sharing it.
| Where to look | Capture | What it tells you |
|---|---|---|
| Enrollment history | Record, workflow, expected event time and actual history | Absence, immediate exit and action failure require different investigations. |
| Trigger evaluation | AND/OR groups and property values at evaluation time | Today's property values may not describe the state when the event happened. |
| Workflow version | The active configuration when the record was evaluated | The current editor may differ from the version used during the failure. |
| Release scope | Existing-record choice, repeat-entry policy and audience size | A trigger correction can unintentionally enroll a large historical audience. |
Platform behaviour and current access requirements: HubSpot: Troubleshoot workflow enrollment ↗
See how the problem happens
A contact qualifies today, but did not qualify then
Consider a workflow requiring a demo request AND a known country. The form creates the contact before another process fills country. Looking at the completed record later makes the rule appear correct, but it does not prove the workflow saw both conditions at evaluation time. Inspect the property's history and trigger semantics. Test a design that waits for the required evidence to exist, then verify the intended entry event. A delay alone does not establish whether the record qualifies. This is a timing example, not a client outcome.
What did you find?
Use the observed behaviour to choose your next check.
Record never enrolled
Test criteria, existing-record settings, re-enrollment and exclusions.
Record enrolled then immediately exited
Inspect goal, suppression and unenrollment history.
Record enrolled but an action failed
Inspect the action result and its specific requirements rather than broadening enrollment.
The tempting fix to avoid
Do not switch on broad re-enrollment or bulk enroll contacts as a debugging shortcut. Those changes can trigger real customer messages.
Test success and the cases that should fail.
One successful test is not enough. Run the applicable cases below with approved test records. Write what happened beside the expected result, so a difference is visible before you release the change.
| Try this | This should happen |
|---|---|
| New eligible record | Enters once and completes the intended test action. |
| Ineligible record | Stays out even if it matches one part of an AND group. |
| Previously enrolled record | Re-enters only when the agreed repeat-entry condition permits it. |
| Suppressed record | Does not receive messages simply because another trigger condition matches. |
| Property arrives later | The chosen trigger design behaves as intended when information added by another tool is delayed. |
Prove the fix
Tick a check only after you have tested it. Your ticks last while this page stays open; they are your own record of checks, not an automatic account test.
0 of 5 checks completed
When you can stop investigating.
Stop changing entry conditions if the record already entered. Investigate the failed action instead. Release an entry-rule correction only when eligible tests enter and excluded tests remain out.
Keep the problem from returning.
Write a clear entry and exit plan for each workflow: object type, entry event, required fields, exclusions, repeat-entry policy and expected action. Keep ownership clear when several workflows can update the same properties. Before release, compare the expected audience with the affected audience and preserve the previous version. A workflow that sends the right message once is not proven if it also enrolls the wrong contacts.
Questions that change the diagnosis.
Should I enroll all existing contacts to test it?
No. Use an approved test record or a deliberately scoped group. Estimate who qualifies and verify exclusions before any historical enrollment.
The criteria tester passes. Why did the record not enter?
Check history and the configuration in effect at the expected time, existing-record settings, prior enrollment and exclusion conditions. A test of current criteria is not a replay of every historical setting.
When you need help
Give the automation owner the test record reference, workflow name, expected entry time and failed condition or action. Remove personal details from shared screenshots. Keep the previous workflow version available and agree who checks the release.
Documentation to keep beside you
Official references checked on 12 October 2026. Menus, permissions and feature availability can change; confirm the details for your account.
Need another pair of eyes?
Show me the step that fails and what you have checked so far. We can trace where the record, event or workflow first goes off course.
Explore the relevant capability ↗ · Read the broader strategy ↗