GHL Trigger Gotchas: When Your Trigger Doesn’t Do What You Think

Triggers seem simple. You pick an event, GHL watches for it, and when it happens, the workflow starts. In practice, almost every trigger in GHL carries a hidden assumption about exactly how that event has to occur, and when your automation does not match that assumption, the trigger simply does not fire, with no warning that anything is wrong.

These are not bugs. Every one of the gotchas below is the platform working exactly as designed. The problem is that the design does not always match what a reasonable person would assume it does, and that gap is where a lot of quietly broken automations come from.

This article covers five of the most common trigger misunderstandings, based on real automations that did not behave the way they were expected to.

For more on how trigger gaps fit the broader diagnostic framework, read out Complete Guide to Debugging GHL Automations.

When you build a workflow that triggers on a tag being added, it is easy to assume that trigger applies to every contact who has that tag. It does not. Tag-based triggers are forward-looking only. They apply to tags applied after the workflow is published, not tags that were already on a contact beforehand.

This means if you have a group of existing contacts who already have a certain tag, and you build a new workflow that triggers on that tag being added, none of those existing contacts will enter the workflow. From the workflow’s perspective, the tag being added is an event, and that event already happened for those contacts before this workflow existed to see it.

This catches people off guard most often when a new automation is meant to apply to an existing segment of contacts, not just future ones.

If you genuinely need to enroll existing contacts after the fact, GHL does give you a way to do it. Select the contacts manually, or build a Smart List filtered down to the group you want, then use Trigger Automation to enroll them directly into the workflow. This runs them through the automation as if the trigger had just fired for them.

Use this carefully. Contacts enrolled this way may not be in the same state a normally triggered contact would be in, and any step further down the workflow that depends on something time sensitive, like a wait step tied to an upcoming appointment, can behave unexpectedly if that appointment date has already passed. Test with a single contact first and confirm the downstream steps behave the way you expect before enrolling a full group this way.

Re-entry controls whether a contact can go through a workflow more than once. Turning it on feels like it should solve the problem of a contact needing to repeat an automation, but re-entry only matters if the actual trigger event happens again. If it never refires, re-entry being on changes nothing.

This trips people up most often with tag-based triggers. If a workflow triggers on a tag being added, and that tag is never removed and reapplied, the contact will not re-enter the workflow no matter how re-entry is configured, because from GHL’s perspective, the triggering event, the tag being added, has not happened a second time. The tag being present is not the trigger. The tag being added is the trigger, and that is a specific event, not an ongoing state.

If you need a contact to go through a workflow again, the trigger event itself has to genuinely occur again. For a tag-based trigger, that usually means removing the tag first, then reapplying it, rather than assuming re-entry alone will make the workflow fire a second time.

A trigger based on a pipeline stage change does not care what mechanism caused that change. It fires whether the stage was updated by a bulk edit, a CSV import, a manual drag-and-drop in the pipeline view, or another automation moving the opportunity for you.

This is worth knowing in both directions. If you are relying on a stage change trigger to catch a specific manual action, be aware that automated or bulk changes will fire it just as reliably, which can cause a workflow to trigger for a large batch of contacts at once if you were not expecting a bulk operation to count. And if you are troubleshooting a workflow that fired unexpectedly, checking whether a bulk edit or import happened recently is a reasonable place to look, since the trigger itself will not tell you what caused it.

The practical takeaway is that a pipeline stage trigger is agnostic about intent. It only cares that the stage changed, not why or how.

A trigger based on a pipeline stage change does not care what mechanism caused that change. It fires whether the stage was updated by a bulk edit, a CSV import, a manual drag-and-drop in the pipeline view, or another automation moving the opportunity for you.

This is worth knowing in both directions. If you are relying on a stage change trigger to catch a specific manual action, be aware that automated or bulk changes will fire it just as reliably, which can cause a workflow to trigger for a large batch of contacts at once if you were not expecting a bulk operation to count. And if you are troubleshooting a workflow that fired unexpectedly, checking whether a bulk edit or import happened recently is a reasonable place to look, since the trigger itself will not tell you what caused it.

The practical takeaway is that a pipeline stage trigger is agnostic about intent. It only cares that the stage changed, not why or how.

GHL has built in appointment reminders that run automatically once a calendar is configured to send them. If you build a custom workflow to send your own reminder, for example an email or SMS twenty four hours before an appointment, without realizing the native reminder is already active on that calendar, contacts can end up receiving both.

This is easy to miss because the native reminder does not show up as a workflow in your automation list. It is a calendar level setting, not something that appears alongside the custom automations you built, which makes it simple to forget it exists, or not realize it was ever turned on in the first place.

The fix is straightforward once you know to look for it. Check the calendar’s own reminder settings before assuming a custom reminder workflow is the only one running. If the native reminder is active and you want your custom workflow to be the only one sending, turn the native reminder off, or decide deliberately which one should own that responsibility rather than letting both run unchecked.

None of these behaviors are bugs. Every one of them is GHL working exactly as it was built to. The problem is that the built in assumption behind each trigger does not always match what feels intuitive, and that mismatch is where a surprising number of quietly broken automations come from. Knowing these five patterns going in means you are far less likely to discover them the hard way, after they have already caused a problem.