Classify the second event
A second form can correct an earlier request, start a new request or repeat the same submission. Two calls can be one unanswered attempt or separate needs. Write the distinction the business wants to preserve. It may require human judgment when the incoming data cannot identify the request reliably; do not force a precise automatic classification from incomplete fields.
Review the scope of enrollment
HighLevel documents workflow re-entry and multiple-opportunity settings as separate controls. An operator should understand which entity is enrolling and whether simultaneous contexts are possible. Do not treat a contact identifier as proof there can be only one active business request. Conversely, do not create a new opportunity for every signal solely because the software allows it.
Protect visibility even when suppressing
Suppressing a second automatic message should not make the later inquiry disappear from the responder’s view. Record the new information or route it for review as appropriate. The customer might be correcting a phone number or changing the requested service. An anti-duplication rule that silently discards meaningful updates can create a different service failure.
Test the intended policy
Use one completed run followed by another event, one event while a run is still active and one event representing a genuinely new request. Compare enrollment history with message attempts. Keep findings tied to the tested configuration; do not claim exactly-once processing across integrations from these cases. If the required distinction cannot be made reliably, choose a conservative manual review boundary and document it. For example, mark a corrected form as an update in the test record and a request for another service as a separate case. Compare their intended response policies without assuming that the software can infer the distinction.
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.
- HighLevel workflow settings — Merchant documentation · help.gohighlevel.com · Merchant-controlled · checked 2026-09-27
- Form Submitted workflow trigger — Merchant documentation · help.gohighlevel.com · Merchant-controlled · checked 2026-09-27
- Execution logs and enrollment history — Merchant documentation · help.gohighlevel.com · Merchant-controlled · checked 2026-09-27