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

A GHL Trigger seems simple enough. 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, you end up with a GHL workflow trigger not firing and 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 our 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. If a contact simply is not re-entering when you expect it to, that can look identical to a contact stuck in a GHL workflow for an entirely different reason, so it is worth ruling out both before you start troubleshooting.

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. That same overlap, another workflow changing the stage at the same moment yours does, is also a common way to end up with a GHL race condition between workflows.

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.

When a workflow has more than one trigger event configured, it is easy to assume all of them need to happen for the workflow to fire, especially if you are thinking about it the way you would think about a condition with multiple requirements. That is not how it works. Multiple trigger conditions on a single workflow are evaluated as OR logic. Any one of them firing is enough to start the workflow, not all of them together.

This matters because if you actually need AND behavior, where a contact should only enter the workflow once multiple specific things are all true, configuring several trigger events on the same workflow will not get you there. It will simply enroll the contact the moment the first one happens, regardless of whether the others have occurred yet.

If you need genuine AND behavior, the trigger itself is not the place to build it. Instead, keep the workflow triggered on a single event, then place an IF/ELSE condition immediately after the trigger that checks for the additional requirements before letting the contact continue. That gives you the AND logic you actually needed, evaluated as a condition rather than assumed at the trigger level.

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.