Fix: GoHighLevel workflow not triggering
The most common GHL workflow failure is a silent one — the trigger never fires and nothing logs. Here's the full diagnostic ladder.
Symptoms — what you're seeing
- You create a workflow in GoHighLevel with a trigger (contact created, pipeline stage changed, form submitted, etc.) but nothing happens
- No error message, no log entry, no indication it ran at all
- The workflow worked once during testing but stopped firing in production
- You test manually by submitting a form or moving a contact and the workflow doesn't execute
- Other workflows in the same sub-account fire fine — just this one is dead
Why this happens
The most common causes, in order of frequency:
1. The workflow is in Draft status. GHL workflows must be explicitly published. Draft workflows run during manual testing but don't fire on real events. Check the toggle in the top-right of the workflow builder — it should show "Published" not "Draft." This is the #1 cause and the fix takes two seconds.
2. Trigger filter mismatch. If your trigger has filters (e.g., "only when pipeline is X" or "only when tag contains Y"), the incoming event might not match. GHL doesn't log filtered-out triggers — it silently discards them. Remove all filters temporarily and test.
3. Webhook URL is stale or misconfigured. If the workflow triggers via webhook from an external system (like n8n), the webhook URL might have changed after a GHL update or re-save. Re-copy the webhook URL from the trigger step and paste it into your calling system.
4. Contact already exists. The "Contact Created" trigger only fires on NEW contacts. If the contact already exists in GHL (even in a different pipeline), the trigger won't fire. Use "Contact Changed" or "Tag Added" instead for existing contacts.
5. Rate limiting / queue delay. GHL queues workflow executions during high-volume periods. A workflow that appears "not triggering" might actually be delayed 5–30 minutes during peak hours. Check the workflow execution log (Automation > Logs) after waiting.
6. Sub-account permissions. If you're using a white-label or agency setup, the sub-account may not have workflow permissions enabled. Check Settings > Company > Workflow Access.
The fix, step by step
- Open the workflow. Confirm the status toggle shows "Published" (not "Draft"). If it shows Draft, publish it and test again immediately.
- Remove ALL trigger filters temporarily. Save and publish. Trigger the event manually (create a test contact, submit a form, move a pipeline stage). If it now fires, your filter was the issue — re-add filters one by one to find which one is too restrictive.
- If the workflow uses a webhook trigger, go to the trigger step, copy the webhook URL fresh, and re-paste it into whatever system calls it. Test with a curl command from your terminal to confirm the URL is live:
curl -X POST "YOUR_GHL_WEBHOOK_URL" \ -H "Content-Type: application/json" \ -d '{"test": true}' - Check the execution log at Automation > Logs. Filter by the workflow name. If you see executions but they're erroring on a step, the trigger IS firing — the problem is downstream, not the trigger.
- If none of the above work, create a brand new workflow with the same trigger, add a single "Send Notification" action to yourself, and test. If the new workflow fires but the old one doesn't, the old workflow has a corrupted state — recreate it from scratch.
Common variations
- "Workflow triggers in test but not live" — almost always the Draft/Published toggle. This catches 60%+ of cases.
- "Workflow triggers for some contacts but not others" — trigger filter or contact-already-exists issue. Check if the failing contacts were created before the workflow was set up.
- "Workflow worked for months then stopped" — GHL platform update changed the webhook URL format, or the trigger filter references a pipeline/tag that was renamed. Check if anything in your GHL setup was recently renamed or reorganized.
- "Workflow triggers twice" — you have two active workflows with the same trigger, or the calling system is sending duplicate webhook POSTs (common with n8n retry logic — see the n8n production reliability checklist).
When this isn't the issue
If the workflow IS triggering (you see it in the execution log) but the expected action doesn't happen:
- Check individual action steps for errors — click each step in the log to see its input/output
- Check that email/SMS actions have valid sender configurations (verified domain, valid phone number)
- Check that API call actions have valid auth tokens that haven't expired
- Check that "Wait" steps aren't set to longer delays than you expect (a 24-hour wait looks identical to "nothing happened" for the first 23 hours)
Need this workflow customized or debugged? Book a 30-min scope call →
Stuck configuring this workflow?
I build and fix n8n workflows for agencies and SaaS teams. 30-minute scope call — bring the problem, leave with an estimate.