A workflow that does nothing gives you no error to read

There is a companion to this page and it is worth knowing which problem you have, because they look nothing alike and the fixes are opposite.

The most common GoHighLevel workflow mistake is about a workflow that will not stop, one that keeps sending after the lead has already replied. This page is about the other failure: a workflow that never starts.

The second one is harder to diagnose, because a workflow that fails loudly leaves an error and a workflow that does nothing leaves nothing at all. No bounce, no failure notice, no red badge. The contact simply sits there.

Every setting below was read off HighLevel’s own documentation on 17 September 2026, and each section links to where we read it.

1. It is still in draft

The first thing to rule out and the one people skip because it feels too obvious to check. HighLevel’s own troubleshooting guidance leads with it: “Double-check that your workflow is published and active.”

A workflow can be fully built, correctly configured and completely inert because it was never published. Saving is not publishing.

2. Allow Re-Entry is off and the contact has already been through

This is the one that wastes the most time, because it fails selectively. The workflow works perfectly for new contacts and does nothing for the person you are testing with, which reads like a trigger problem and is not one.

From HighLevel’s workflow settings documentation, Allow Re-Entry decides whether “a contact can enter this workflow more than once”, or whether they “can only enter and complete this workflow one time only”.

If it is off and your test contact completed the workflow yesterday, they will never enter again. Nothing about that is reported to you.

The exception that makes this worse before it makes it better

Appointment and invoice triggers ignore the setting entirely. The documentation is explicit: workflows using an appointment or invoice-based trigger “will always allow a contact to enter multiple times, regardless of whether this setting is enabled or disabled”.

So the behaviour is genuinely inconsistent between trigger types, and if your mental model came from an appointment workflow, a tag-based one will surprise you. Knowing this turns two confusing symptoms into one rule.

3. Stop on Response already ended it

Also from the settings documentation: with Stop on Response enabled, “the workflow will end for a contact if they respond to a message sent from this specific workflow”.

That is usually what you want, and it is the correct fix for the problem in the companion post above. It becomes a triggering problem when a contact replied once, exited, and you now expect later steps to reach them. They exited. They are not coming back.

Note the scope: a response to a message sent from this specific workflow. A reply in a different conversation does not end it.

4. The Time Window paused the action

A Time Window “restricts when communication actions (like sending an SMS or email) can execute”.

The important part is what happens outside the window. The action is not skipped and not failed. It “will be paused and will resume at the next available time slot”. So a workflow tested at 9pm against a 9am to 5pm window looks broken and is working exactly as configured. Check back the next morning before changing anything.

5. The timezone setting is not the one you assumed

Two options, and they behave differently at the edges.

Setting	Behaviour
Account Timezone	“All time-based actions will execute based on the timezone set for the entire location”
Contact Timezone	“Actions will execute based on the individual timezone of each contact”

The trap is in the fallback. On Contact Timezone, if a contact has no timezone set on their profile, “the system will use the account timezone as a fallback”. Imported contacts frequently have no timezone, so a workflow can behave one way for form leads and another for a CSV import, from a single setting, with no indication which path a given contact took.

6. Two workflows share the same trigger

HighLevel’s guidance is direct about this: “Avoid setting up multiple workflows with the same trigger to prevent unintended actions.”

In an inherited account this is the norm rather than the exception. The workflow you are watching may be firing perfectly while a second one, built months earlier by somebody else on the same trigger, moves the contact, changes the tag or ends the sequence underneath it.

7. Duplicate or near-duplicate tags

The same guidance: “Ensure tags are unique and descriptive to avoid confusion in workflows.”

lead-hot, hot lead and Hot Lead are three tags. A workflow listening for one of them is inert against the other two, and in an account where several people have added tags by hand over a year, this is extremely common.

What we could not verify, and did not quote

• Whether Allow Re-Entry defaults to on or off. The settings page describes both states and does not state a default. Check it on your own workflow rather than assuming either way.
• The exact behaviour of Execution Logs and Enrollment History. The documentation references workflow history in passing, showing whether actions ran in account or contact timezone, but does not specify what the logs record or how far back they go. They are still the first place to look, we just cannot quote their guarantees.

The order worth checking them in

Not the order above, which is by cause. This is by how long each takes to rule out.

1. Is it published (5 seconds)
2. Has this contact been through it before, and is Allow Re-Entry off (30 seconds)
3. Did they reply to something this workflow sent (30 seconds)
4. Is it outside the Time Window right now (10 seconds)
5. Does the contact have a timezone set (1 minute)
6. Search every workflow for the same trigger (5 minutes)
7. Search the tag list for near-duplicates (5 minutes)

Most accounts we audit stop at 2. Almost none get past 6.