A HighLevel Automation or Workflow Did Not Fire: A Safe Troubleshooting Checklist
A HighLevel Automation or Workflow Did Not Fire: A Safe Troubleshooting Checklist
When an automation appears not to fire, the failure may be at enrollment, a condition, a wait step, or an action such as email or SMS delivery. Avoid repeatedly adding the same real contact or republishing random changes; that can produce duplicate messages, opportunities, or tasks. Trace one contact through the workflow instead.
1. Define the expected result
Record the workflow name, sub-account, trigger, expected action, contact record link, event time and time zone, and what actually happened. Confirm that the contact used the exact event the trigger expects, for example, the correct form, tag, pipeline stage, appointment status, or inbound message. Similar names are a common source of confusion.
Use a clearly labeled internal test contact with an authorized email and phone. Do not use a client’s record unless the test is approved. Pause before any step that could send a real message, charge a payment method, create an opportunity, or notify an external party.
2. Confirm the workflow is publishable and live
Open Automation, select the workflow, and check its publication status. HighLevel distinguishes pre-publish configuration problems from execution errors: configuration issues appear in the workflow error panel, while errors occurring after a contact starts are found in Execution Logs.[1]
Review visible warnings and required fields. HighLevel’s Resolve Errors panel can identify supported trigger or action configuration problems and open the affected step. Hiding an error indicator does not fix the underlying issue, and pre-publish validation does not detect every possible runtime problem.[1]
3. Verify the trigger and filters
Open the trigger and compare every filter with the test contact and event. Check exact asset, status, tag spelling, pipeline, calendar, assigned user, custom field, and date/time assumptions. If several triggers exist, determine which one should have enrolled the contact.
Check whether the event happened before the workflow was published. Automations generally act on qualifying events as they occur; do not assume publication will retroactively process earlier contacts unless the feature explicitly says so.
4. Review workflow settings
HighLevel’s workflow settings control re-entry, multiple opportunities, stop-on-response behavior, timing, and sender details.[2] A contact may not enter again if Allow Re-entry is disabled or may still be active in a prior run. Opportunity-based behavior may differ when one contact has multiple opportunities. A reply can end a sequence when Stop on Response is enabled.
Also inspect the workflow time zone, communication window, and wait steps. The workflow may be functioning but waiting until an allowed day or hour. Verify default sender email, phone number, and assigned-user values. Do not expand sending windows or bypass consent rules merely to force a test.
5. Trace the contact in Execution Logs
Use Execution Logs to determine whether the contact enrolled and where processing stopped.
- No execution: focus on publication state, trigger event, filters, and re-entry eligibility.
- Waiting: inspect the scheduled resume time, time zone, business-hour window, event date, and goal conditions.
- Skipped: read the branch or condition result and compare it with the contact’s values at that moment.
- Failed: capture the action name, error text, and timestamp. Check the relevant integration, sender, field mapping, or required data.
- Completed but no message received: distinguish workflow success from downstream delivery. Review the conversation/email/SMS status, consent and DND state, spam folder, address/number validity, and provider logs available to an administrator.
Do not reconnect integrations, remove consent restrictions, or manually replay a workflow without understanding the impact. A replay can resend previous actions.
6. Escalate with evidence
Send support the workflow name and link, contact link, trigger event and time zone, expected action, publication status, screenshots of trigger filters and relevant settings, and the Execution Log entry or error. Mask sensitive contact data and never include credentials or one-time codes.
After a fix, run one controlled test from a fresh qualifying event, then verify enrollment, each critical step, and the final destination. Monitor the first few live executions before considering the issue resolved.