What people think it does
The common mental model is that a workflow watches a contact continuously, and the moment they match the criteria again it runs again. Set a 30-minute delay, and you imagine a loop that keeps nudging until something changes.
That is not what happens, and the gap between the two models is where most broken follow-up sequences come from.
What it actually does
Enrolment is an event, not a state. A contact enters when they newly meet the trigger, and by default they only ever enter once. Re-enrolment has to be switched on deliberately, and even then it only fires when a re-enrolment trigger property changes — not simply because the contact still matches.
- A contact who already matched the criteria before the workflow existed will not be pulled in retroactively.
- A contact sitting in a delay step is not re-evaluated against the enrolment criteria while they wait.
- Changing the criteria later does not re-run anyone who already went through.
The most common symptom is a follow-up ladder that works perfectly in testing and then goes quiet in production — because the test contact was new and the real ones were not.
Where the 30 minutes comes from
A 30-minute delay inside a workflow is a pause in the sequence, not a polling interval. Nothing is being checked during it. When the delay ends, the contact moves to the next action whether or not anything has changed in the meantime.
If you want the sequence to stop when the customer replies, that has to be an explicit goal or an if/then branch. Otherwise the second and third messages go out to someone who already answered you, which is worse than not following up at all.
A follow-up that keeps going after the customer has replied does not read as diligent. It reads as automated, and they treat everything else you send the same way.
How to build it so it holds
- Turn re-enrolment on explicitly, and be precise about which property change should re-trigger it.
- Put a goal on the workflow so a reply, a booking or a won deal removes them.
- Branch on the actual outcome rather than assuming the delay implies one.
- Test with a contact that already exists and already matches, not a fresh one.
None of this is exotic. It is just the difference between building against how the tool behaves and building against how you assumed it behaves.