Allow Re-entry in GHL workflows: when to turn it on and when it double-texts contacts

The message usually arrives from the client, not the contact. "Somebody just told me they got the same text from us twice. Is that normal?" You open the account, find the workflow, and the sequence looks exactly the way you built it. Every step is correct. It simply ran for that person two times.

Very often the root of it is one toggle in the workflow settings: Allow Re-entry. It is not a bug and it is not a hidden switch. It does precisely what HighLevel says it does. The problem is that it gets turned on, or left on, without anybody deciding what kind of workflow they are building.

This post is that decision. What the setting actually controls, the one exception that overrides it, the workflows where re-entry is the right answer, the ones where it double-texts people, and the guardrails that make either choice safe.

What the setting actually does

HighLevel's workflow settings overview is short and specific about it. Allow Re-entry is the toggle that determines whether a contact can enter the workflow more than once. With it on, a contact can re-enter after they have fully completed the workflow or after they have been manually removed. With it off, a contact can enter and complete the workflow one time only.

Then comes the sentence that matters most and gets read least: a contact cannot re-enter while they are still active in the workflow. Re-entry is not "run this again every time the trigger fires." It is "allow a fresh run once the previous one is over."

That gives you three states for any contact and any workflow:

• Never entered. The trigger fires and they go in, regardless of the toggle.
• Currently active. They are sitting on a wait step or partway through the actions. A second trigger event does not start a second run, whichever way the toggle is set.
• Finished or removed. This is the only state where the toggle decides anything. On, they can go through again. Off, they cannot.

Most double-text incidents live in that third state, and most confusion about the setting comes from expecting it to govern the second.

The exception that overrides the toggle

The same article carries a caveat that explains a lot of support tickets: workflows that use an appointment or invoice-based trigger will always allow a contact to enter multiple times.

That is the sensible design. Every booking is its own event and deserves its own confirmation and reminders. Every invoice is its own bill. But it means that for appointment and invoice workflows, the re-entry toggle is not your control. If a contact is getting more reminders than you expect, turning re-entry off will not change it. You have to look at how many appointments exist for that contact and what else in the account is sending reminders.

A related setting sits next to it. Allow multiple Opportunities, per the same overview, lets a contact with several opportunities enter the workflow as a separate instance for each one. With it off, the contact enters only for the first opportunity that meets the trigger criteria. If you run opportunity-based workflows and see parallel runs, that toggle is the first place to look, not re-entry.

When re-entry is the right call

Turn it on when every trigger event is genuinely a new thing that deserves a full response. The test I use: if the contact did this again next month, would I want them to get the whole sequence again, from the first message, as if it were the first time?

Workflows that usually pass that test:

• Inquiry acknowledgement. A contact who fills out the contact form in March and again in September is asking two separate questions. Both deserve a reply and an internal notification.
• Per-visit follow-up. A review request or a post-visit check-in tied to a completed visit. A returning customer should get one per visit, not one per lifetime.
• Internal routing. Assign-a-task or notify-a-user workflows. Running them again for a new event is the point.
• Re-engagement after a real gap. A win-back sequence you want to repeat for somebody who goes quiet a second time, as long as something prevents it from looping on a short cycle.

When it double-texts contacts

Leave it off when the workflow is a journey, meaning something a person should experience once. Welcome sequences, long nurtures, onboarding drips, a lead magnet delivery followed by five days of education. Repeating any of those from the top reads as a broken system, because from the contact's side it is one.

The trouble is rarely that someone turned on re-entry for a nurture on purpose. It is that a nurture with re-entry on gets re-triggered by something nobody connected to it. The patterns I see most:

• Tag triggers that get re-applied. A nurture starts when a tag is added. Months later, another workflow, an import, or a staff member's bulk action adds that tag again to people who already finished. With re-entry on, every one of them starts the nurture from message one.
• Form resubmissions. A lead submits the opt-in form, finishes the sequence, then submits again to get the download link they lost. They get the download and the entire sequence.
• Manual removal as a reset. Somebody removes a contact from a workflow to stop a message, which HighLevel counts as one of the conditions that allows re-entry. The next matching trigger event starts them over.
• Imports and bulk edits. Re-importing a list or bulk-editing contacts can satisfy the trigger of any workflow tied to those changes, across people who finished months ago. Read which triggers a bulk change can hit before you run it.

In our operating experience the tag case is the most common and the hardest to see, because the workflow that re-applies the tag is usually not the one that sends. You read the nurture, it looks fine. The cause is in a different workflow entirely. Mapping which workflows can fire which triggers is the same exercise we walked through for trigger coverage in GHL, and it is worth doing before you touch a tag in bulk.

The active-contact gap nobody plans for

The opposite failure is quieter. Because a contact cannot re-enter while still active, a second trigger event during a long workflow does not produce a second run. HighLevel's documentation does not describe a queue for that event, and there is an open request on HighLevel's ideas board asking for an option to queue contacts who want to re-enter while still in the workflow.

Practically: if your inquiry acknowledgement workflow has a seven-day wait at the end, a contact who submits a second form on day three does not get a second acknowledgement, and the team does not get a second notification. Re-entry on does not help, because they are still active.

The fix is structural. Keep event-shaped workflows short so contacts finish quickly, and move the long follow-up into a separate workflow they are added to. Short workflows with re-entry on behave the way people expect. Long workflows with re-entry on behave in ways nobody can predict without reading the timeline.

Guardrails that make either choice safe

Re-entry is a blunt instrument. HighLevel gives you sharper ones, and a re-entry workflow without at least one of them is a double-text waiting for an import.

Stop on Response. Per the settings overview, with it enabled the workflow ends for a contact if they respond to a message sent from that specific workflow. Note the scope: it is replies to this workflow's messages, not any message. A reply to a different workflow, or to a message a staff member sent by hand, does not end this one.

Goal Events. HighLevel's Goal Event action moves a contact to the defined goal step the moment they meet the goal, regardless of where they were in the workflow. Goal types include Form Submitted, Payment Received, Invoice Paid, Email Events, Clicked a Trigger Link, Contact Tag Added or Removed, Appointment Status and User Replied. For a nurture whose real purpose is a booking, an Appointment Status goal ends the selling the moment the person books. There is also a setting for a contact who reaches the goal step without meeting it: end the workflow, continue anyway, or wait until the goal is met.

An entry check. The first action in a re-entry workflow can be an if/else that looks for a marker, such as a "nurture completed" tag or a date field, and ends the run for anyone who already has it. That turns re-entry from "anyone can repeat" into "only the people I mean can repeat." We covered when branching is worth the complexity in if/else branching in GHL workflows; this is one of the cases where it clearly is.

The Time Window. It does not prevent duplicates, but it limits when they can land. The settings overview says the Time Window restricts when communication actions execute, and an action scheduled outside it is paused. A mistaken bulk re-trigger at 11 p.m. that waits until morning gives you hours to catch it.

How to tell what actually happened

When a client reports a double text, do not guess from the settings screen. HighLevel documents Execution Logs and Enrollment History as the places to debug workflow runs. Filter to the contact and answer three questions:

• Did they enroll in this workflow twice, or did two different workflows send similar content?
• If twice, what event started the second enrollment, and which workflow or person caused it?
• Were they finished or removed before the second run, which is the only way re-entry could have allowed it?

Two workflows sending near-identical copy is a surprisingly common answer. It usually means somebody rebuilt a sequence and published the new version without unpublishing the old one, which is a portfolio hygiene problem more than a settings problem.

A one-line rule for each workflow

Before you publish, write one line in the workflow name or description: "event" or "journey."

• Event: re-entry on, keep it short, add an entry check if the trigger can be re-applied by anything else.
• Journey: re-entry off, Stop on Response on, a Goal Event for the outcome the journey exists to produce.

Appointment and invoice workflows are always events whether you like it or not, so design their reminders on the assumption that a contact may hold more than one booking.

Doing this across a portfolio

Checking one workflow takes a minute. Checking every published workflow in every sub-account for re-entry, Stop on Response, and the trigger that feeds it is the kind of audit that gets planned and never finished. It is also the kind that matters most after a snapshot load, when settings arrive exactly as somebody else left them, which is part of why snapshots deserve an audit before you trust one.

GHL Command is how I do it on my own accounts. Claude reads each workflow's full action list, so you can ask it which journeys lack a goal step and which other workflows add the tags those journeys trigger on, then check the settings that matter in the order above. It works across every sub-account from one place, running on your own machine so client credentials stay on your computer.

Flat $97/mo, every sub-account you manage included, never billed per account.

Frequently asked questions

What does Allow Re-entry do?
Per HighLevel's settings overview, it determines whether a contact can enter the workflow more than once. On, a contact can re-enter after fully completing the workflow or being manually removed. Off, they can enter and complete it one time only. Either way, a contact cannot re-enter while still active in it.

Why does my appointment workflow run more than once with re-entry off?
HighLevel documents that workflows using an appointment or invoice-based trigger always allow a contact to enter multiple times. Each booking or invoice is its own event, so the toggle is not the control for those workflows.

Does a second trigger restart a contact who is still in the workflow?
No. A contact cannot re-enter while active. The docs do not describe a queue for that event, and there is a public feature request asking for one. Keep event workflows short so contacts finish before the next event is likely.

How do I stop a re-entry workflow from texting someone who replied or booked?
Stop on Response ends the workflow when the contact replies to a message from that workflow. A Goal Event moves them to the goal step the moment they meet it, with goal types including Appointment Status and User Replied. An if/else entry check can skip anyone carrying a "completed" marker.

How can I confirm a contact really ran a workflow twice?
Open the workflow's Enrollment History and Execution Logs, filter to the contact, and look for two enrollments and the event that started each. Often the answer is two different workflows sending similar copy, not re-entry at all.