GoHighLevel Workflow Not Firing? 12 Causes and How to Fix Each

When a GoHighLevel workflow “doesn’t fire”, it almost never means HighLevel is broken. It means one of a dozen settings is doing exactly what it was told. The trick is finding which one, and that is fastest when you stop looking at the workflow as a whole and follow one affected contact through it.

Prefer a guided check? The free GHL Troubleshooter asks a few yes/no questions about your workflow and shows the most likely cause first.

First, find out which kind of failure you have

Pick one contact who should have gone through the workflow. Open the workflow and look at its enrollment history and execution logs for that contact (HighLevel labels these slightly differently between versions, but both live inside the workflow). You will land in one of three situations:

This one step saves hours. Without it, people start toggling settings at random, which usually creates a second problem.

Group A: the contact never entered

1. The workflow is still in draft

Workflows have a draft/published toggle. A draft workflow can be saved, edited and tested manually, but it does not enroll anyone from its triggers. It is the single most common cause, especially after duplicating a workflow, because copies start as drafts.

Fix: publish the workflow, then trigger the event again with a test contact.

2. The trigger is watching a different event

A “Form Submitted” trigger only fires for the forms selected in its filter. The same goes for calendars on appointment triggers, pipelines and stages on opportunity triggers, and specific tags on tag triggers. Rebuilt or duplicated forms and calendars have new IDs, so a trigger pointing at the old one silently stops matching.

Fix: open the trigger and confirm that the exact form, survey, calendar, pipeline or tag is selected, not one with a similar name.

3. A trigger filter excludes this contact

Filters narrow who can enter: “has tag”, “does not have tag”, “contact type is lead”, and so on. A filter like does not have tag: client will quietly exclude anyone who was ever tagged as a client, even years ago.

Fix: read each filter against the affected contact’s record. If one condition fails, the contact does not enter, and you will not see an error, because nothing went wrong.

4. Re-entry is turned off

Each workflow has a setting that controls whether a contact can enter more than once. With re-entry off, a person who submitted your form last year and submits again today is ignored the second time. This catches a lot of businesses with returning customers.

Fix: if repeat entries should be allowed, turn on re-entry. But be careful: with re-entry on and no guard, someone who submits a form twice in a minute gets two of everything. A common pattern is to allow re-entry and add a filter that excludes contacts who received a short-lived tag (for example in-new-lead-sequence) that your workflow adds at the start and removes at the end.

5. The event never actually reached HighLevel

If leads come from Facebook, a website builder, Zapier or a webhook, the “form submitted” may have happened somewhere else entirely. If there is no contact, or the contact has no record of the submission, the problem is upstream of the workflow. See the Facebook lead ads troubleshooting guide for that path.

Fix: check the contact’s activity for the event itself. No event, no trigger.

Group B: the contact entered but an action did not run

6. The contact is on Do Not Disturb (DND) for that channel

If a contact replied STOP, or someone enabled DND on their record, SMS (or the specific channel) will not send. That is the correct behaviour: opt-outs must be honoured.

Fix: check the DND settings on the contact. Do not switch DND off to “make it work” unless the contact has genuinely opted back in.

7. The contact is missing the data the action needs

An SMS action needs a valid phone number; an email action needs an email address. Contacts from some sources arrive with a malformed number (missing country code) or an empty field, and the action is skipped.

Fix: look at the contact’s phone and email format. For recurring issues, fix the form or integration mapping rather than patching contacts one by one.

8. Email sender settings are wrong

Emails that silently fail are often caused by the From address or name: a From field containing a name rather than an email, a sending domain that is not verified, or a custom value used in the From field that resolves to nothing. Templates with broken merge fields like {{contact.first_name} (one missing brace) can also cause problems.

Fix: use a verified sending domain, check the From name and address in the action and in your email settings, and preview the email with a real contact to confirm merge fields resolve.

9. SMS failed at the carrier level

If the logs show the SMS was sent but the conversation shows a failed or undelivered status, the workflow did its job and the carrier rejected the message. For US numbers, unregistered or rejected A2P 10DLC traffic is the leading cause.

Fix: check the error on the message, then your A2P registration status. The A2P 10DLC rejection guide covers this in detail.

10. A wait step is still waiting (or waiting for the wrong thing)

Wait steps can wait for a time, for an event such as a reply, or until a specific date or time window. A contact sitting on a wait step looks exactly like a workflow “not firing” to someone checking the next action. Wait steps tied to appointment times are also affected by time zone settings.

Fix: check where the contact currently sits in the workflow. If waits are tied to appointment time, confirm the account, calendar and user time zones agree.

Group C: the contact left early

11. A goal event was reached

Goal events pull a contact out of the workflow (or jump them to a later point) when something happens, like booking an appointment. That is usually what you want, but a goal set too broadly, such as “any appointment booked”, can remove people who booked something unrelated.

Fix: make the goal condition as specific as the workflow’s purpose.

12. Another workflow removed them, or two workflows are competing

Workflows can remove contacts from other workflows, and “stop on response” settings end sequences when a contact replies. In older accounts it is common to find two workflows reacting to the same trigger: one sends messages, the other removes the contact from the first.

Fix: search your workflows for “remove from workflow” actions and for duplicate triggers on the same form, tag or calendar. Consolidating to one workflow per responsibility prevents this permanently.

A five-minute diagnostic routine

1. Choose one affected contact and write down exactly what should have happened and when.
2. Open the workflow and confirm it is published.
3. Check enrollment history: did the contact enter? If not, compare the trigger and each filter with the contact record, then check re-entry.
4. If they entered, open the execution log and find the first step that was skipped or failed. Read the reason.
5. If they left early, check goal events, stop-on-response settings and other workflows that act on this contact.
6. Fix one thing, then test with a new test contact, not the original one (which may already be blocked by re-entry rules).

How to stop this from happening again

• One responsibility per workflow. “New lead follow-up” and “Appointment reminders” should be separate workflows that do not overlap.
• Name workflows by trigger and purpose, for example Form: Quote request → New lead follow-up. Avoid “Copy of…”.
• Decide re-entry on purpose for every workflow and write the reason in the workflow description.
• Keep test contacts with your own phone and email for every important path, and rerun them after changes.
• Review execution errors monthly. Problems usually show up in the logs long before someone notices fewer leads.

If you have worked through this list and the workflow still is not behaving, or you would rather not spend the afternoon on it, GoHighLevel troubleshooting is exactly the kind of work I do: trace the contact, find the cause, fix it and explain what happened.