> For the complete documentation index, see [llms.txt](https://seedly-crm.gitbook.io/seedly-crm-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://seedly-crm.gitbook.io/seedly-crm-docs/common-gohighlevel-problems-and-how-to-fix-them/ghl-workflows-not-triggering.md). # Workflows Not Triggering ![An automation workflow with a broken connection that has stopped firing](/files/uZ5OTpgbpVXTJ8Cysabv) You know what nobody warns you about with automation? The day it quietly stops. Not with an error, not with an alert, not with a red banner across the top of your dashboard... just silence. A workflow that stops firing is one of the most expensive bugs in any CRM precisely because nothing tells you it happened. Leads stop getting follow-ups. Reminders never send. The booking confirmation that should fire the second someone fills out your form just... doesn't. And the worst part is the lag. You find out weeks later, when a prospect emails to ask why they never heard back, or a client forwards you a thread where your "automated nurture" went completely dark. By then the damage is done, the lead is cold, and you are reverse-engineering a sequence you built three months ago and barely remember. Been there. It is a special kind of stomach drop. So let me walk through why GoHighLevel workflows stop triggering, then exactly how to find the break without losing your whole afternoon to it. ## Why a GoHighLevel workflow stops triggering Here is the thing about a dead workflow: there is rarely one single cause, and the real one is almost never the dramatic one you are imagining. Run through these from most common to least, because the boring answers near the top catch most cases. 1. **The workflow is not published.** I know. I KNOW. But this is the number one culprit and it is humbling every time. A workflow saved in draft does absolutely nothing. It sits there looking complete, fully built, every step in place, and fires for nobody. Confirm the toggle at the top is set to Publish, not Draft, before you touch anything else. 2. **The contact is on a suppression list.** If that person unsubscribed, hard bounced, or got marked do-not-contact, your automation emails to them fail silently. No bounce-back, no warning, just nothing landing. Agencies burn hours tearing apart their logic when the contact was suppressed the whole time and the workflow was working perfectly. 3. **The trigger conditions are not actually met.** Filters on the trigger (a tag, a source, a pipeline stage) are usually narrower than you remember setting them. So the contacts you SWEAR should be entering never enter at all. The workflow is not broken; the front door just never opened for them. 4. **Re-entry is off.** By default a contact will not re-enter a workflow it has already been through once. This one is sneaky because of HOW you test. You run yourself through it, it works, you tweak something, you run YOURSELF through again to check... and nothing happens. Looks broken. It is working exactly as configured. You are just the wrong test subject now. 5. **A wait or action step is misconfigured.** A wait step pointed at the wrong event, or an email action with no template actually selected, will stall the entire sequence behind it. The contact enters fine, moves a step or two, then parks forever at the broken one. Everything downstream goes dark. ## How to debug it Here is the move, and it is the opposite of what most people do. The fastest path is NOT to sit and stare at the workflow canvas hunting for the broken wire. It is to read the contact's history and let them tell you where they got stuck. ![Decision flow for debugging a workflow that will not trigger](/files/FFEPGAE53lirp2mdT6Zt) 1. **Open the contact record and check the activity log.** This is the whole game. The log tells you whether the contact entered the workflow at all. If they never entered, your problem lives in the trigger or its filters, full stop. If they entered and then stalled, your problem is a step somewhere inside. Two completely different investigations, and the log tells you which one you are in before you waste a second on the wrong one. 2. **Check suppression status on that contact next.** Before you go spelunking through every step, rule out the dumb-but-common one. An unsubscribed or bounced contact will not receive email actions, period. Confirm they are clean. 3. **Walk the workflow step by step from the entry point.** Now you go through it, but with purpose, confirming each trigger filter, each wait condition, each action is configured the way you ASSUME it is. Assumptions are where these things hide. The step you are most confident about is usually the one lying to you. 4. **Test with a fresh contact that meets the trigger.** Not the one you have already run through ten times (remember re-entry). Make a brand new test contact that genuinely satisfies the trigger conditions, and watch it move. Clean test, clean signal. ## The real problem underneath Notice the pattern in all of this. Every single debugging step exists because you cannot actually SEE what your automations are doing or why one stopped. The system is a black box. Debugging means clicking through screen after screen, eyeballing toggles, hoping you spot the one thing that is off. There is no diff. No history. No "here is what changed and when." Just you, a canvas, and a gut feeling. That visibility gap is annoying on a Tuesday afternoon. But it becomes a genuine trap the moment you ever want to leave, because you cannot migrate automations you cannot fully describe. You do not own a documented system; you own a pile of clicks inside someone else's platform, and that is exactly the position they want you in. The fix is to document every workflow and how the pieces connect, which is the first real step in [our full GoHighLevel migration playbook](https://seedlycrm.com/blog/migrate-from-ghl-with-patchyhub). Once your automations are written down and version-controlled, a workflow that breaks stops being a silent mystery you stumble onto three weeks late. It shows up as a visible change, in plain sight, the way a broken thing actually should... --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://seedly-crm.gitbook.io/seedly-crm-docs/common-gohighlevel-problems-and-how-to-fix-them/ghl-workflows-not-triggering.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.