Your GoHighLevel workflow is not firing, a lead is sitting untouched, and you are staring at a builder that looks exactly like it did when it worked. This is the most common support emergency on the platform, and it has a property worth knowing before you touch anything: in the overwhelming majority of cases the workflow is behaving exactly as configured: the gap is between what was configured and what you believe was configured. That is good news, because configuration gaps have a diagnostic order, and walking it beats poking triggers at random.
This is the checklist I run on real accounts, ordered by how often each cause turns out to be the one. It resolves most cases in under fifteen minutes, and the last section covers the genuinely weird ones: the workflows that fire but appear not to.
Quick answer
- First check publish status: the workflow must be Published, not Draft: the single most common cause, and the most invisible after an editing session.
- Then the trigger’s filters: the trigger fired for a contact that did not match a filter (wrong tag spelling, different form, pipeline mismatch). Filters are AND conditions: all must match.
- Then re-entry rules: the contact was already in the workflow (or has been through it) and re-entry is off: for that contact, the workflow will not start again.
- Then look INSIDE: the workflow fired but a wait step, condition branch, or business-hours window is holding or diverting the contact: check the contact’s position in the workflow’s execution log.
- The fired-but-silent cases: DND, missing phone/email, or an unconfigured sender make actions fail while the workflow runs: the execution log names the failing step.
| Symptom | Most likely cause | Where to confirm |
|---|---|---|
| Nothing happens for any contact | Draft status, or trigger filter matches nobody | Workflow status + trigger filters |
| Works for some contacts, not others | Filter mismatch or re-entry blocked | Contact’s tags/fields vs filters; enrollment history |
| Fired once, never again | Re-entry disabled | Workflow settings |
| Contact enters, nothing sends | Wait/branch holding, or action failing (DND, no sender) | Execution log, contact’s step position |
| Worked last week, dead today | Recent edit, republish missed, or renamed asset in a filter | Version history, filter references |
Print that table for your team and half your future tickets disappear. The rest of the article is the table with its reasons.
Why is my GoHighLevel workflow not firing?
The usual causes, in order: the workflow is in Draft instead of Published; the trigger’s filters exclude the contact (all filters must match); re-entry settings block contacts who were already enrolled; or the workflow actually fired and a wait step, condition branch or failing action (DND, missing sender) hides the progress. The execution log confirms which.
The diagnostic order, explained
1. Publish status: the embarrassing champion
Workflows edit in a draft state and require republishing; a colleague “just checking something” who leaves without publishing turns the workflow off as thoroughly as any bug. It takes five seconds to verify and it is the top cause by a wide margin, which is exactly why it goes first: never debug filters on a workflow that is not published. Corollary for teams: agree that whoever opens the editor confirms status on the way out.
2. Trigger filters: the AND that everyone reads as OR
A trigger with three filters requires ALL three to match: tag added AND pipeline is X AND source is Y. The classic failures are mundane: a tag filter pointing at “web-lead” while the form applies “Web Lead” (spelling and case matter), a form-submitted trigger scoped to a form that was later duplicated (the filter still points at the original), or a pipeline filter referencing a stage that was renamed. Check the actual contact against each filter literally, one by one, reading values from the contact record rather than from memory: the mismatch is usually visible in thirty seconds once you look at data instead of intentions.
3. Re-entry: the one-shot surprise
Every workflow has enrollment rules controlling whether a contact who already passed through (or is currently inside) can enter again. With re-entry off (a correct default for many flows), your test contact who went through yesterday will never trigger it today, and the “it works for new leads but not for Juan” mystery is solved: Juan already used his ticket. For testing, either enable re-entry temporarily or use fresh test contacts each round: seasoned implementers keep a small stable of disposable test contacts for exactly this.
4. Inside the workflow: fired but parked
When enrollment is confirmed (the contact appears in the workflow’s history), the question changes from “why didn’t it fire?” to “where is the contact standing?”. Wait steps park contacts by design, and a “wait until 9am” configured against the ACCOUNT’s timezone surprises operators expecting the contact’s local time. Condition branches send contacts down the path their data matches, which may be the branch with no actions in it (the silent else). And business-hours windows on messaging steps hold sends until the window opens. The execution log shows the contact’s exact position and the timestamps of each step: read it before theorizing: it answers most “inside” mysteries by itself.
5. Fired and failing: the silent action errors
The subtlest family: the workflow runs perfectly and an ACTION fails. An SMS step for a contact with DND enabled, or no valid phone; an email step with the sending domain not configured or the contact bounced previously; a webhook step pointing at a dead endpoint. The workflow moves on (or logs the failure) and the human experience is “the workflow didn’t fire”, when it fired and hit a wall. The execution log again names the failing step and reason: this family is why the log, not the builder canvas, is where debugging actually happens. If a webhook step is involved, remember the failure may live on the receiving side: a dead endpoint fails silently from the workflow’s point of view.
When it is genuinely the platform
Rarely, but honestly: delayed trigger processing during platform incidents does happen. The tell is scope: if MULTIPLE unrelated workflows on multiple accounts went quiet simultaneously, check the platform’s status page before dismantling your configuration. If it is one workflow while its siblings run fine, the cause is in your account, and the checklist above finds it. (The platform’s fast shipping pace occasionally moves settings around after releases: one more reason to verify against the current interface rather than an old tutorial, as noted in the honest review.)
Common mistakes while debugging
- Editing five things at once: change one variable, test, observe: the shotgun edit that “fixes” it also destroys the knowledge of what was broken.
- Testing with a used contact: re-entry rules make previous test runs invisible walls. Fresh contact, every serious test.
- Trusting memory over the contact record: the tag you “know” the contact has is exactly what needs verifying character by character.
- Ignoring the execution log: the builder shows intentions; the log shows history. Debug in the log, design in the builder.
- Deleting and rebuilding as first resort: it sometimes works (you rebuilt the config you MEANT the first time) and teaches nothing: the same gap will return in the next build.
If the workflow runs but the opportunity never moves, the fault is downstream: GoHighLevel pipeline not working walks the stage and automation checks in order.
Frequently asked questions
The workflow’s enrollment history lists every contact that entered with timestamps, and the contact record shows current workflow memberships. If the contact never appears there, the problem is upstream (status, trigger, filters, re-entry); if it appears, the problem is inside (waits, branches, failing actions).
Almost always re-entry: existing contacts already passed through and the workflow will not enroll them again. The other candidate is a filter matching properties only fresh leads have, like a source field that older contacts lack.
Contacts already enrolled continue on the version of the path they are walking; trigger and filter changes govern NEW enrollments. That is why edits mid-campaign need the execution log to tell which cohort a given contact belongs to.
The step executed and the send failed or was blocked: DND on the contact, missing or invalid phone, or the number not configured for the sub-account. The execution detail shows the step’s outcome; the fix lives on the contact or in phone settings, not in the workflow logic.
They can both act on the same contact and produce confusing combined effects (competing tags, double messages), though they do not block each other’s firing. If symptoms look like interference, list every workflow the contact belongs to: untangling overlapping automations is its own project, and naming conventions are the prevention.
Diagnostic order verified across real production accounts, current as of July 2026. This site earns an affiliate commission if you subscribe through our links, at no extra cost to you; the checklist works the same either way.
The habit that prevents the next one
Almost every “workflow not firing” traces to a gap between configuration and belief, and gaps grow in the dark: unnamed workflows, filters nobody documented, edits nobody republished, test contacts nobody refreshed. The teams that stop having these emergencies did not get smarter about debugging: they made the configuration legible: naming conventions, a republish habit, disposable test contacts, and the execution log as the first tab opened rather than the last. Fix today’s workflow with the checklist; fix next month’s by making your account a place where beliefs and configuration are the same thing.
