When a send goes out through GoHighLevel, it lands in GHL's own conversation AND in this platform's conversation_messages copy (kept deliberately so the thread survives a GHL disconnect). Since GHL's send API often returns no message id, the two copies can never be matched by id. The merge therefore also pairs outbound rows by content and time.
Also called: duplicate texts in the thread · message showing twice · double messages
- 1Every GHL message id is collected into a seen-set first
- 2Any stored row whose id is already in that set is dropped
- 3Remaining outbound rows are matched by same direction + same trimmed body (SMS) or same subject (email) within a 5-minute window
- 4Pairing is strictly one-to-one, so deliberately re-sending the same text twice still shows twice
A text sent through a connected CRM ended up recorded twice — once by the CRM and once here — and because that send often returned no message id, the two copies had nothing in common to match on. Builders saw every estimate text they sent listed twice in the customer's history, which made the thread look unreliable at exactly the moment they were checking whether a quote had gone out. Duplicates are now collapsed by comparing the message itself, so one send reads as one row.
- Duplicate outbound rows in a customer thread
- A builder unable to tell a genuine re-send from a display bug
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →