GoHighLevel Workflow Audit Case Study: The Duplicate Tag Action We Caught
The workflow ran. The problem was that its final status did not tell the truth clearly.
During QA of our executive-coaching booking workflow, we found two actions applying the same reminder tag. It was not a dramatic outage. It was the kind of small ambiguity that makes support, reporting and future edits unreliable.
The intended behavior
After a lead is qualified, the workflow sends the discovery-call invitation, waits two days and checks for an appointment. If the lead has not booked, the workflow sends one reminder. The contact record should then show that the follow-up sequence has completed.
The symptom
The lower branch applied the reminder-sent tag and then applied the same status again at the end. A team member filtering contacts could see “reminder sent,” but could not distinguish an active record from one whose booking follow-up was finished.
The root cause
The final action had been copied while building the branch and never renamed to match its actual purpose. Visual workflow builders make duplication fast; they do not guarantee the copied state still represents the business event.
The repair
We created a distinct booking follow-up complete tag and assigned it to the final action. We did not add another message or inflate the workflow. The repair made the record state explicit.
How we retested it
- Confirm the new tag exists in the account.
- Enter a fresh test contact through the qualified trigger.
- Force the no-booking branch.
- Confirm the reminder sends once.
- Confirm the reminder-sent and follow-up-complete statuses are both present.
- Confirm a contact who books does not receive the unnecessary reminder.
Why this small issue matters
Status data is used by filters, reports, other workflows and humans. When one tag means two events, every downstream decision becomes less trustworthy. The immediate fix took minutes. Finding the same ambiguity after hundreds of contacts would take much longer.
What to inspect in your workflows
- Copied actions whose name and configuration no longer match
- One tag used for entered, sent, replied and completed states
- Branches that send after the goal has already been reached
- Final actions hidden below the normal canvas view
- Statuses that no team member or report actually uses
This is an internal build case study, not a claim about a client result. It demonstrates the standard we use: trace the symptom to the business state, make the smallest repair and retest both the changed path and the path that should remain untouched.
The wider snapshot test process adds dependency review, clean-account installation and a release decision.
One Comment