Deduplication

When a customer sends a follow-up email without using the per-ticket reply address (e.g. they hit “Reply” in a different mail client, forwarded the original, or wrote a fresh email about the same problem), Scitor matches it back to their existing ticket instead of opening a new one.

How matching works

For every non-plus-addressed inbound, Scitor computes:

• sender_hash — sha256 of the lowercased sender email.
• subject_norm_hash — sha256 of the normalized subject. Normalization lowercases, repeatedly strips Re:, Fwd:, AW:, Sv:, VS: (with optional bracketed counts like Re[2]:), and collapses whitespace.

It then looks up inbound_threads for a row matching (installation_id, sender_hash, subject_norm_hash) updated within the configured window. If found, the new email becomes a reply on the stored ticket. If not, a new ticket is created and the thread is recorded for next time.

When the matched ticket is closed, Reopen on Reply takes over.

Configuration

inbound:
  dedup:
    enabled: true
    window: 7d

• enabled — toggle the entire feature. Default true.
• window — how far back to look for an existing thread. Accepts 30s, 15m, 2h, 7d. Default 7d.

Why subject + sender, not just headers?

Scitor’s outbound emails do set Message-ID and threading headers, and inbound mail clients usually echo them back via In-Reply-To / References — but only when the customer hits “Reply” in the same client thread. Real-world support traffic is messier: customers forward to a colleague who then writes back, customers compose fresh emails about the same issue (“Following up on my last email”), and mobile clients sometimes drop reference headers entirely. Subject + sender catches the common case reliably; header-based matching can be layered on later as a fallback.

Limits

• Dedup is per (installation, sender, normalized subject). Two unrelated tickets with the same subject from the same sender will collapse onto the most recent one. If that’s a problem for your team, use distinct subjects in your saved replies.
• Plus-addressed replies (hashid+nodeId@…) always bypass dedup — they go straight to the addressed ticket.
• The inbound_threads table is keyed on the hash, so subject content is never stored in plaintext.