HubSpot decides whether an inbound email belongs to an existing conversation by evaluating standard headers (In-Reply-To, References, Message-ID) along with subject and participant continuity. That works when the sender is a person using a mail client that replies properly. It breaks down when the sender is a machine.
We’re a B2B reseller, and a large share of our inbound comes from automated procurement platforms, order systems, and invoicing portals. Those systems don’t reply in any protocol sense. They compose each notification as a brand new message, so it arrives with no In-Reply-To and no References at all. Others rewrite or strip the headers in transit. Either way, HubSpot has nothing to match on.
That produces two failure modes. Messages that belong to an existing ticket arrive headerless and create a new ticket instead. And unrelated messages that happen to share a subject and participants get grouped into a single ticket. Both are corrected by hand, every day.
The fix doesn’t require a new header or anything proprietary. Have Help Desk stamp a deterministic, HubSpot-issued token into the References header on every outbound message, something along the lines of ticketID@portalID.hubspot.com. On inbound, check for that token first and route on it when present, then fall back to the existing header and subject logic when it isn’t. Optionally allow the same identifier to be injected into the outbound subject line and parsed on the way back in, for senders that preserve subjects but not headers.
The key point is that the identifier is HubSpot’s own. Threading no longer depends on the correspondent preserving a chain they never created in the first place.