Skip to content
Book a Consultation

You built a workflow in GoHighLevel, a lead fills out the form or gets tagged, and nothing happens. The contact never appears in the workflow, no internal notification arrives, and the follow-up sequence never starts. In other cases the workflow seems to start but stalls: the contact is enrolled, yet the first SMS or email never goes out.

These two situations look similar from the outside but have different causes. A workflow that never enrolls anyone usually has a trigger, filter, publish, or re-entry problem. A workflow that enrolls contacts but does not deliver messages usually has an action, sender, Do Not Disturb (DND), or phone-registration problem. This guide walks through both, using the diagnostic tools HighLevel provides inside the workflow builder.

Quick diagnostic checklist

  • Is the workflow set to Publish, not Draft?
  • Does the trigger’s Trigger Stats panel show the contact as Attempted, Matched, or Unmatched?
  • Do the trigger filters match the exact form, tag, pipeline, or stage the event used?
  • Has this contact already been through the workflow while Allow Re-entry is off?
  • Did the event happen after the workflow was published?
  • Does Enrollment History show the contact entering and then being removed?
  • Do Execution Logs show a failed or skipped action?
  • Does the contact have DND enabled, or lack the email or phone number the action needs?
  • Is the sending number registered for A2P 10DLC if you text US recipients?

Common causes

1. The workflow is still in Draft

HighLevel’s builder has a Draft/Publish toggle in the top-right corner. According to the workflow builder documentation, a draft workflow does not trigger or run actions for real. Saving and publishing are separate steps, so a workflow can be fully saved and still inactive.

2. Publish-blocking errors

HighLevel lets you save a workflow that contains configuration errors, but it will not publish one with unresolved publish-blocking errors. If you try, you see a message that the workflow can’t be published yet. The Resolve Errors sidebar lists each issue with an “Open step” link.

3. Trigger filters that do not match the real event

Many “not triggering” reports come from a filter that does not match what actually happened. Examples:

  • A Form Submitted trigger filtered with “Form Is” set to an older copy of the form, while the live page uses a newer one.
  • A Pipeline Stage Changed trigger filtered to one pipeline while the opportunity lives in another.
  • A Contact Created trigger with several tag filters. HighLevel’s Contact Created documentation notes that multiple tag filters use AND logic, so the contact must satisfy all of them.

4. The event did not actually happen the way you think

Several triggers respond only to specific events, and HighLevel documents important exceptions:

  • The Form Submitted trigger works with forms built inside HighLevel. A form from an external tool needs an integration or webhook instead.
  • The Contact Tag trigger fires only when a tag is added or removed after the workflow is active. Contacts that already carry the tag are not enrolled retroactively.
  • Contact Created does not fire for bulk imports, and it does not fire again if the new submission is merged into an existing contact record.

If Allow Duplicate Contact is turned off under Settings > Business Profile > Contact Deduplication Preferences, a repeat form submission with the same email updates the existing contact rather than creating a new one. A workflow triggered by Contact Created will stay silent for that returning lead, while a workflow triggered by Form Submitted will still run.

5. Allow Re-entry is off

In Workflow Settings, Allow Re-entry controls whether a contact can go through the same workflow more than once. When it is off, a contact who already entered once will not enter again. HighLevel notes that appointment- and invoice-triggered workflows are an exception and always allow re-entry. For opportunity-based workflows, the related Allow multiple Opportunities setting decides whether each opportunity for the same contact creates its own enrollment.

6. The contact entered, then left early

If Enrollment History shows the contact entering and then leaving, look at how it left. Stop on Response removes a contact who replies to a message sent from that workflow. Another workflow may also remove the contact with a workflow action, which Enrollment History labels “Removed by External Workflow Action.”

7. Actions are held by the Time Window

The Time Window setting restricts actions to chosen hours and days. An action scheduled outside that window pauses and resumes at the next allowed slot. A lead who submits a form at 9:00 p.m. may not receive anything until the next morning, which can look like a failure if you test in the evening.

8. Messages are blocked, not the workflow

When enrollment succeeds but a message never arrives, the cause is often outside the workflow logic:

  • DND. HighLevel’s DND feature can block outbound messages per channel (Email, SMS, Calls, and others) or on all channels. A contact who texted STOP remains blocked until they opt back in.
  • Missing contact data. An SMS action cannot reach a contact without a valid mobile number, and an email action needs an email address.
  • A2P 10DLC registration. Business texting to US recipients from standard 10-digit numbers requires brand and campaign registration. HighLevel’s SMS troubleshooting guide lists error codes such as 30032, 30033, and 30034 for incomplete or suspended registration, and 30007 for carrier filtering.

9. Overlapping workflows

HighLevel states that when several workflows share the same trigger tag, all of them activate. Two workflows reacting to the same tag can send duplicate messages, or one can remove the contact from the other.

Step-by-step troubleshooting

  1. Confirm the status. Open the workflow and look at the Draft/Publish toggle. If it says Draft, resolve any listed errors and publish. Remember that only events occurring after publishing will enroll contacts.
  2. Read the trigger narration. HighLevel shows a plain-language summary of each trigger’s filters on the trigger card. Read it aloud and compare it to the event. “Form is Contact Us (v2)” will not match a submission from “Contact Us.”
  3. Open Trigger Stats. The Trigger Stats panel lists contacts the trigger evaluated as Attempted, Matched, or Unmatched, with the reason a contact did or did not match. Stats cover the last 30 days.
    • If your contact is not listed at all, the event never reached this trigger. Go back to cause 4: wrong trigger type, external form, tag added before publishing, or an import.
    • If the contact is Unmatched, the listed reason points to the failing filter. Adjust the filter or the data.
    • If the contact is Matched but not enrolled, check Allow Re-entry and whether the contact already completed the workflow.
  4. Check Enrollment History. In the workflow, open Execution Logs and switch to the Enrollment History tab. Filter the date range around the test. Look for the contact and its status, such as Workflow Completed or Removed by Workflow Action.
  5. Check Execution Logs. If the contact entered, the Execution Logs tab shows each action, its status, and an Executed On timestamp. A failed action is highlighted. A missing action with a future time usually means a Wait step or the Time Window is holding it.
  6. Inspect the contact record. Confirm DND settings per channel, a valid email and phone number, and the tags or custom field values your filters and If/Else branches rely on.
  7. Check the message itself. For SMS failures, open the conversation and read the error code on the failed message, then look it up in HighLevel’s error dictionary. For email, confirm the From Email in workflow settings matches a sending domain you have set up.
  8. Retest with a fresh contact. HighLevel’s own guidance is to test with a contact that has never entered the workflow. Reusing one test contact repeatedly is one of the easiest ways to get misleading results, and the builder notes that Test Workflow is not fully reliable when the same contact is reused.

Platform-specific guidance: Inbound Webhook triggers

If leads come from an external system through the Inbound Webhook trigger, there are extra points to verify. Per HighLevel’s Inbound Webhook documentation, it is a premium trigger with a limited number of free executions per sub-account, it accepts JSON only, and creating or matching a contact requires an email or phone field in the payload. Keys should not contain spaces. If the sending system changes its payload structure, you need to re-select the mapping reference so the workflow reads the new fields.

A controlled test request shows whether the problem is the sender or the workflow. Use test data only, and treat the webhook URL like a password: HighLevel recommends replacing it if it is exposed.

// Node.js 18+ test sender (placeholder URL, test data only)
const url = "https://YOUR_INBOUND_WEBHOOK_URL";

const payload = {
  first_name: "Test",
  last_name: "Lead",
  email: "test.lead+ghl@example.com",
  phone: "+15555550123",
  lead_source: "website_contact_form"
};

const res = await fetch(url, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(payload)
});
console.log(res.status, await res.text());

If the request succeeds but the workflow does not run, the problem is inside HighLevel (mapping, filters, publish status). If the request fails or never appears among the received samples in the trigger, the problem is on the sending side: URL, method, or payload format.

Sample workflow (hypothetical): The following is an illustrative example of a lead-intake workflow and where it typically breaks. It is not a description of a specific client project.

ElementDescription
TriggerForm Submitted, “Form Is” set to the website contact form.
ApplicationsHighLevel form, contacts, opportunities, email, SMS (LC Phone or another connected provider).
Data inputsName, email, mobile phone, service requested, consent checkbox.
Processing logicDeduplication updates or creates the contact; the workflow creates an opportunity in the “New Leads” stage, sends an internal notification to the owner, then an If/Else branch sends SMS only when a phone number exists and consent was given.
Expected outputsOne contact, one opportunity, one internal email, one acknowledgment message.
Failure pointsWorkflow left in Draft; “Form Is” pointing to an old form; Allow Re-entry off for returning leads; Time Window delaying SMS overnight; DND or unregistered number blocking SMS.
Error handlingAn If/Else fallback sends email when SMS is not possible; the owner notification goes out regardless of the lead’s channel preferences because it is internal.
Validation and testingSubmit with a new test contact, a repeat test contact, a contact with no phone, and a contact with SMS DND; check Trigger Stats, Enrollment History, and Execution Logs for each.
Business applicationEvery inquiry reaches a pipeline and a person, even when the automated message cannot be delivered.

Native HighLevel features cover this entire flow when the form lives inside HighLevel. Custom development becomes useful when leads come from an external site or app, when data needs validation or reformatting before it reaches the CRM, or when failures should be logged somewhere outside HighLevel. That is typically where API integration work or an n8n layer comes in.

How to confirm the issue is fixed

  • Submit the real trigger event (not only Test Workflow) with a new test contact, and confirm Trigger Stats shows it as Matched.
  • Confirm Enrollment History shows the contact entering, and Execution Logs shows each action completing with a timestamp.
  • Confirm the outputs exist: the opportunity is in the correct stage, the internal notification arrived, and the message shows as delivered in Conversations.
  • Repeat with a returning contact if the workflow should handle repeat inquiries.

Common mistakes to avoid

  • Testing only with the same contact over and over, then concluding the workflow is broken.
  • Expecting a newly published tag workflow to enroll contacts who already had the tag.
  • Duplicating a form or workflow and leaving filters pointing to the original.
  • Turning off DND for a contact who opted out just to make a test pass. Opt-outs must be respected; use a separate test contact instead.
  • Building several workflows on the same trigger without documenting which one owns which messages.

Prevention and monitoring

  • Name triggers and forms clearly, including a version or date, so a filter pointing to the wrong asset stands out.
  • Keep a workflow inventory listing each trigger, filters, re-entry setting, and messages sent, so overlaps are visible.
  • Review Trigger Stats weekly for high Unmatched counts. A sudden rise usually means a form, tag, or pipeline was renamed or replaced.
  • Add an internal failure path, such as a task for a team member when a message cannot be sent.
  • Monitor A2P status for any number used in workflows, and check delivery errors in Conversations after changing message content.

If the workflow is part of a larger lead-handling process, our guide on automating lead capture and follow-up covers the surrounding design, and CRM data not syncing between applications covers problems when data arrives from other tools.

Still having trouble with your GoHighLevel workflow?

Tell Modern Streamline which triggers and actions you’re using, what your workflow should do, and what is happening instead. We can review your setup and discuss an appropriate solution through our GoHighLevel automation services.

Get Help With Your Automation

FAQ

Why does my GoHighLevel workflow work in Test Workflow but not with real leads?

Test Workflow runs the actions for a contact you pick; it does not prove the trigger fires. Real enrollment depends on the workflow being published, the filters matching the live event, and re-entry rules. Check Trigger Stats for the real contact to see whether it matched.

Why didn’t contacts who already had the tag enter my workflow?

The Contact Tag trigger reacts to a tag being added or removed after the workflow is active. It does not enroll contacts that already carry the tag. To include them, remove and re-add the tag or add them to the workflow manually, after confirming that is appropriate for those contacts.

Why did my contact enter the workflow but never get the SMS?

The most common reasons are SMS DND on the contact, a missing or invalid mobile number, the Time Window holding the action, or a carrier or A2P registration error. The Execution Logs and the failed message in Conversations will show which one applies.

Sources