Independent HighLevel affiliate publication. We may earn a commission if you buy through links on this page, at no extra cost to you.

Practical guide

Investigate two acknowledgements before adding another rule

Last materially reviewed 2026-09-27

Quick answerFind both sending paths and their initiating events. Duplication may come from repeated calls, multiple workflows or an integration—not just one re-entry setting.
What to know

Preserve the two observations

Record when the two messages were sent, their channel and the relevant request context without exposing private content unnecessarily. Similar wording does not prove that the same workflow sent both. One could come from a phone provider, a built-in text-back feature or a separate automation. Start with the observed messages rather than choosing a suspected setting in advance.

What to know

Trace each message to its source

Compare execution and enrollment history for the relevant period. Look for two incoming events, two active paths or repeated integration delivery. HighLevel’s built-in missed-call behavior is particularly worth checking when the caller redialed. Do not assume that disabling re-entry in one workflow prevents another sender from responding to the same business event.

What to know

Choose the intended owner

Once the paths are understood, decide which one should own the acknowledgement. Preserve any other useful function before changing a live path. A workflow that also assigns staff or records an exception should not be removed wholesale merely because its customer message duplicated another. Make the narrowest authorized correction and document what responsibility remains elsewhere.

What to know

Test suppression and legitimate repetition

The repaired path should prevent the unwanted duplicate without hiding a later genuine request. Use synthetic cases inside and outside the chosen repeat policy and include a customer reply between signals. Keep the old observations as evidence. If the cause remains uncertain, avoid stacking more timers and tags; use a limited manual response while tracing the actual event chain. For a fictional caller who rings twice and submits a form, keep three event rows even if the expected outcome is one acknowledgement. The rows explain why suppression was intentional rather than losing the evidence of a later contact attempt.

Continue when useful

Next: Re-entry and repeated signals are not the same problem

Decide whether another signal should restart, update or remain outside the workflow. Re-entry settings alone do not define a complete duplicate-response policy.

Open Re-entry and repeated signals are not the same problem →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Execution logs and enrollment history — Merchant documentation · help.gohighlevel.com · Merchant-controlled · checked 2026-09-27
  2. HighLevel missed-call text back — Merchant documentation · help.gohighlevel.com · Merchant-controlled · checked 2026-09-27
  3. HighLevel workflow settings — Merchant documentation · help.gohighlevel.com · Merchant-controlled · checked 2026-09-27