scitor.yaml recipe · Works on every plan
Stop follow-up emails from opening duplicate tickets
When a customer replies to an old email thread instead of the notification on their open ticket, Scitor matches it back to the existing Issue by sender and normalized subject — instead of filing a second, disconnected ticket. This is on by default; the recipe below just makes the behavior explicit and tunable.
What this does
dedup.enabled matches a new inbound email to an existing thread by sender plus normalized subject, within dedup.window. reopen_on_reply reopens a closed ticket if the customer replies after it was closed, instead of creating a new one. rate_limit caps how many tickets one sender can open per minute/hour — useful if a customer's mail client is misconfigured and resending the same message repeatedly.
What it does not do
It doesn't merge two tickets that were already created separately — dedup only applies going forward, to new inbound emails. All of this is enabled by default with these exact values, so this recipe is mainly useful if you want to change the window or turn a bound off (max_per_minute: 0), not to enable something that was off.
The config
Add this to .github/scitor.yaml — shown with the platform's own defaults.
# .github/scitor.yaml
inbound:
reopen_on_reply: true
rate_limit:
max_per_minute: 5 # 0 disables this bound
max_per_hour: 30 # 0 disables this bound
dedup:
enabled: true
window: 7dFull reference: scitor.yaml — Inbound configuration
One customer, one thread
Takes under 5 minutes. Free tier available. No credit card required.