GHL workflows do not break randomly. Every time a workflow fails silently, stops firing, or sends the wrong message to the wrong person, there is a specific reason — and in most cases, that reason points back to how the workflow was built, not to a bug in the platform.
After building and auditing GHL accounts for agencies across different industries, I see the same causes come up repeatedly. Here is what they are and why they happen.
1. The Trigger Was Never Tested in Production Conditions
Most workflow problems start with the trigger. A workflow is only as reliable as the condition that fires it, and triggers behave differently depending on how contacts enter your system. A workflow built to fire when a form is submitted will not fire if the same contact submits again and the "allow re-entry" setting is off. A trigger set to fire on a tag being added will not fire if the tag was already on the contact from a previous interaction.
These edge cases are invisible during initial setup if you only test the clean path. In production, real contacts do not always behave the way you expect. If nobody tested what happens when a contact re-enters, you find out when a real lead does not get followed up with.
2. Filters Are Missing or Too Broad
Filters inside a workflow tell GHL which contacts should actually go through the steps and which should skip or exit. When filters are missing, everyone goes through everything — including contacts who should not. When filters are too broad, you get workflows that fire on the wrong segment, sending the wrong message to people who have nothing to do with that campaign.
This is especially common in accounts that have grown over time. A workflow built for one campaign gets partially repurposed for another, the filters get adjusted but not fully cleaned up, and suddenly contacts from two different funnels are getting tangled together.
3. The Workflow Was Built on Top of an Existing One
One of the most common sources of chaos in GHL accounts is layered workflows — new automations built on top of old ones without fully understanding what the old ones were doing. You add a new follow-up sequence, but the original workflow is still running and now contacts are getting two sets of messages. You update a tag name in one place but not in the workflow that depends on it. The system is not broken, exactly. It is just doing something you did not intend.
A workflow audit is almost always the first thing I do when taking over an existing account. You cannot build on top of something you do not understand.
4. Phone Numbers Are Not Properly Registered for SMS
If your workflows include SMS steps — which most lead follow-up sequences should — and your phone numbers are not A2P 10DLC registered, your texts are being filtered by carriers before they ever reach your contacts. The workflow fires, GHL shows the message as sent, and nothing arrives. This is one of the most frustrating problems because it looks like the workflow is working when it is not.
A2P registration is not optional. It is a carrier-level requirement for business text messaging in the US, and GHL accounts that skip it have SMS automations that quietly fail.
5. Someone Edited the Workflow While It Was Live
GHL allows you to edit active workflows. This is useful, but it also means that changes made mid-flight can affect contacts who are already inside the workflow. If you change the timing of a step or remove a branch that contacts were waiting on, those contacts can get stuck or skip steps entirely. In a busy account where multiple people have access, this can happen without anyone realizing it.
Best practice is to duplicate a workflow, make changes in the copy, test it, then switch over — rather than editing the live version directly.
6. The Workflow Is Too Long and Too Complex
There is a temptation in GHL to build one workflow that handles every scenario. One massive automation with branches for every possible condition. These workflows are hard to read, hard to debug, and when something goes wrong it is difficult to isolate where. Breaking complex logic into smaller, focused workflows that hand off to each other is almost always the better approach. It takes more planning upfront but saves significant time when something needs to be fixed.
The Common Thread
Almost every broken workflow I have seen comes down to one of these causes. And almost every one of them is preventable with proper planning, testing, and architecture before the workflow goes live. The fix is rarely complicated — but finding it requires understanding how the whole system was built, not just the individual step that appears to be failing.
If your workflows keep breaking, the answer is not to fix them again. It is to rebuild them correctly.