Why Your HubSpot Workflow Only Reached a Fraction of Your Contacts

A nurture sequence we were asked to look at earlier this year had sent 288 welcome emails. The next three steps went to roughly 20 contacts each. Nobody had touched the workflow between the sends, the branch logic was correct when we read it, and every test contact we pushed through it behaved exactly as designed.

The workflow was waiting on a property that an external system set, and it was waiting for about five business days. Most of the audience took longer than that. By the time the property arrived, the delay had expired, the branch had already read an empty value, and those contacts had been routed to a static list where the workflow ended permanently.

This is the most common shape of the problem, and the reason it is hard to spot is that nothing is broken. Every component is doing what it was told.

Start by separating the two failures

Before touching anything, work out which of two very different problems you have:

1. Contacts never enrolled. The workflow's enrollment count is lower than your audience.
2. Contacts enrolled and then stopped. The enrollment count is right and the send counts fall away as the workflow progresses.

Open one affected contact record, go to the workflow membership section, and read the enrollment history. It gives you a timestamped record of every action, where the contact sits now, and which branch it took. One contact usually explains the whole cohort, and it takes about ninety seconds.

If the contact is not in the workflow at all, read the section below on enrollment. If it is in the workflow and parked, read the section on delays.

Cause 1: the enrollment setting you chose when you turned it on

When you switch a workflow on, HubSpot asks whether to enrol contacts who already meet the criteria, or only those who meet it from now on. It is a one-time question at activation, and the answer is not displayed on the canvas afterwards. Six months later, nobody remembers which box was ticked.

We watched this take out a campaign aimed at roughly 10,000 contacts. The audience already existed; the workflow was switched on with the new-contacts-only path; a fraction of the list ever enrolled. It took a HubSpot support session to confirm, because there is nothing in the workflow interface that shows the choice after the fact.

The recovery is the part worth writing down, because the instinct is wrong. Do not re-run the workflow. Re-enrollment rules, delays and any send-once logic all apply again, and you will spend a day arguing with the tool. Instead:

1. Build a list of the contacts who should have received the email.
2. Send the email to that list directly.
3. Apply the "has not already received this email" filter so anyone who did get it is protected.

On the campaign above that recovered the full send in a single afternoon.

Related traps in the same family: suppression lists on the workflow that are broader than anyone realised, enrollment criteria referencing a property the audience does not have populated, and contacts blocked by the once-per-contact enrollment default. HubSpot's enrollment troubleshooting guide walks the rest of the list.

Cause 2: a delay that expires before the thing it is waiting for

This is the 288 case, and it is the one that produces the sharpest drop.

A delay is an assumption stated in units of time. "Wait five business days" really means "I believe the thing I need will have happened within five business days." The moment the underlying process is slower than that assumption for part of your audience, the branch after the delay reads an empty property and routes those contacts somewhere they should not go.

The failure is silent because the property does eventually populate. Look at the contact a fortnight later and everything appears correct. The record shows the value the branch could not see at the moment it mattered.

The two minute diagnostic. On one affected contact:

1. Open the record, choose Actions, then view all properties, find the property the branch reads, and open its Details. That tells you what actually sets the property, which is frequently not what the person who built the workflow believed. Integration-set properties are the usual culprit.
2. Go to Contacts, apply advanced filters, and ask for records where that property is known and membership of the list the failing branch dumps people into. Any record returned is a contact who satisfied the condition after the workflow had given up on them.

On the nurture above that filter returned three contacts, which was enough to prove the mechanism in a single screenshot.

The fix, and the obvious fix we rejected. The obvious answer is "delay until the property is known" instead of a fixed window. We did not use it, because contacts who genuinely never activate would then sit in the workflow forever and receive nothing at all, which is a worse outcome than the bug.

What shipped instead: an active list of contacts who completed the flow and then activated, feeding a second, shorter workflow that catches them up. The primary delay window was extended to sit somewhere in the fifteen to thirty day range to reduce how many people needed catching. Total build time was under an hour.

The general principle is worth keeping: size a delay against the slowest realistic run of the dependency, not the average, and build an explicit path for the records that arrive late. HubSpot's own guidance on delays makes the same point in miniature, recommending a short delay before any branch whose criteria depend on a property update or on engagement with a previous step.

Cause 3: branch order

HubSpot evaluates if/then branches in the order they are stacked, and a record that matches the first branch never gets tested against the others, even when it also matches them. If your broadest condition is at the top, everything falls into it and the branches underneath look broken.

Read the branches top to bottom and ask, for each one, whether a record matching it could also have matched something above. If yes, that is your answer. Reordering is a thirty second fix and it is the second thing to check after enrollment.

Cause 4: re-enrollment is off

Re-enrollment is off by default. If your workflow is meant to catch a contact every time something happens, and it was never switched on, each contact goes through exactly once. This shows up as "it worked for a while and then stopped," which is a different presentation of the same problem and sends people looking in the wrong place.

Cause 5: the workflow is fine and the send is being suppressed

If the enrollment history shows the contact reached the send step and no email exists, the workflow has done its job and the email tool is dropping the contact. That is a separate diagnosis: marketing contact status, subscription type, bounce history, low engagement suppression or consent basis. We wrote that one up separately in why your HubSpot email only reached part of your list, because the causes and the fixes do not overlap with anything above.

How to read an enrollment history without guessing

The enrollment history on the contact record is the single most under-used diagnostic in HubSpot, largely because people skim it rather than read it. Four things to take from it every time:

The enrollment timestamp against the trigger event. If a contact enrolled hours or days after they met the criteria, something batched them: an import, an integration sync, or a scheduled list refresh. That lag is often the whole explanation.

Where the record is sitting right now. "In a delay until 14 August" is a completely different problem from "completed" or "goal met." Completed with no sends means the record took a branch that had no actions on it.

Which branch it took, and when. Compare that against what the property looked like at that timestamp, not what it looks like now. This is the step people skip, and it is the step that solves delay problems.

Whether it left early. Goal criteria, suppression lists and unenrollment actions all remove a record mid-flight, and all of them appear in the history rather than on the canvas.

Do this on three contacts, not one: one that behaved correctly, one that stalled, and one that never enrolled. The differences between the three are the diagnosis, and it is faster than reasoning about the workflow in the abstract.

How to stop shipping this

Six habits that between them account for most of the prevention:

• Run the enrollment preview before switching anything on, and reconcile the number it returns against the audience you expect. A discrepancy at this point costs nothing to fix. Ten minutes later it costs a send.
• Decide the enrollment setting deliberately and record the choice. It is a one-time question with permanent consequences and no visible answer afterwards.
• Write the delay assumption into the workflow description. One sentence: "waits five business days for X, which is set by Y." The next person to open it inherits the assumption instead of rediscovering it. This costs fifteen seconds and it is the highest return habit on this list.
• Give every branch a fallback path. An if/then with no else is a silent drop, and silent drops do not appear in any report.
• Test with a record that fails, not only with one that succeeds. Most workflow QA consists of pushing a perfect test contact through and confirming it arrives. That proves the happy path and nothing else. Build a test record with the property missing and confirm it lands somewhere you chose.
• Check enrolled against completed a week after launch, not just on the day. Delay-related failures are invisible on day one by definition, which is exactly why they survive QA.

The last one deserves a calendar entry rather than good intentions. A workflow that looked perfect at launch and quietly failed in week two is the single most common piece of remedial work that reaches us, and the diagnosis is almost never difficult once somebody actually looks.

Across roughly 300 workflow builds in our own delivery data, the ones that come back for rework are almost never the complicated ones. They are the simple ones built against an assumption nobody wrote down. Structured agency automation work is mostly this: not clever branching, but documented assumptions and an explicit path for every record.

The bottom line

When a HubSpot workflow reaches fewer people than it enrolled, the tool is usually correct and the model is wrong. Read one stuck contact's enrollment history, decide whether you have an enrollment problem or a stall, and work the list above in order.

If you are carrying a portfolio of inherited client portals full of workflows nobody on your team built, that diagnosis is the work, and it is the work our white-label HubSpot support team does under your brand. Our guide to HubSpot workflow automation for agencies covers the build side of the same discipline.