# Correlate unchanged system emails into one ticket using configurable rules and a time window
**URL:** https://community.zammad.org/t/correlate-unchanged-system-emails-into-one-ticket-using-configurable-rules-and-a-time-window/21317
**Category:** Feature requests
**Created:** [October 6, 2026, 5:46am UTC](https://community.zammad.org/t/correlate-unchanged-system-emails-into-one-ticket-using-configurable-rules-and-a-time-window/21317 "2026-10-06T05:46:01Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@SmileitsMe1976](https://community.zammad.org/u/SmileitsMe1976)
#### Post date: [October 6, 2026, 5:46am UTC](https://community.zammad.org/t/correlate-unchanged-system-emails-into-one-ticket-using-configurable-rules-and-a-time-window/21317/1 "2026-10-06T05:46:01Z")
1. What is your original issue/pain point you want to solve?
We receive automatically generated system emails in our service desk. One restart or recovery sequence can generate 10–30 separate messages for the same system. These become separate tickets, although they belong to one operational incident. This creates manual work, clutters queues and inflates ticket-volume and waiting-time reporting.
The sending systems and their email formats cannot be changed. Zammad must process the original incoming emails as they arrive, without requiring changes to the sender, custom headers, ticket numbers or an external preprocessing service.
1. Which are one or two concrete situations where this problem hurts the most?
A recent real example produced ten emails and ten tickets within approximately four minutes: one restart notification, seven component-availability notifications, one configuration-link notification and one database-connection notification. The messages identify the same system, but have different event codes and subjects. Some follow-up messages arrive before the restart notification.
Another use case is recurring alerts for the same unresolved system condition. During mobile/on-call work, manually sorting and merging these tickets is particularly cumbersome.
1. Why is it not solvable with the Zammad standard?
We reviewed the documentation for additional email follow-up detection, postmaster filters, triggers and monitoring integrations. We have not found a documented configurable rule that extracts a system identifier from an unchanged email, finds a matching incident ticket within a defined time window and appends the email before creating an additional ticket.
Changing group, tags or custom attributes does not itself solve this. Matching only the sender is too broad; matching only identical subjects misses related messages with different event codes. Monitoring integrations requiring a different message format or an external API adapter do not meet the unchanged-email requirement. If a supported configuration already covers this, a pointer would be very welcome.
1. What is your expectation/what do you want to achieve?
An opt-in, configurable incoming-email correlation feature, ideally available in postmaster rules:
- Scope rules to selected mailboxes, senders and customers/organizations.
- Extract a stable system identifier from the subject or body using configurable patterns.
- Match related event types within a configurable time window, for example ten minutes, and selected ticket states.
- Create one incident ticket and append every matching original email as a separate article, preserving content, attachments and timestamps.
- Keep customers and systems strictly separated, including customers using identical private IP addresses.
- Handle out-of-order arrival and simultaneous delivery without creating multiple tickets for the same event.
- Distinguish a subsequent restart/new incident from late messages belonging to the previous one; do not group unrelated faults just because they are close in time.
- Do not automatically close the incident merely because an individual message says “cleared” or “recovered”.
- Provide a rule-test/preview and an audit trail explaining the assignment; use normal ticket creation when matching is ambiguous.
The desired outcome is one incident = one ticket, with all original messages retained, instead of creating many tickets and merging them afterwards. This would be useful across system-alert sources and does not require AI.
Your Zammad environment:
- Self-hosted on Ubuntu; exact installed Zammad version not verified for this request.
- Average concurrent agent count: not measured.
- Average tickets a day: not measured; individual system events can produce up to 30 emails.
- Roles/people involved: service desk agents, technicians and administrators handling customer system alerts, including mobile/on-call work.
Related discussion: [AI Ticket Merger](https://community.zammad.org/t/ai-ticket-merger/20499) — this request focuses on deterministic correlation during email ingestion, before additional tickets are created.
All examples are anonymized and vendor-neutral.
---
### Author:  [@YetAnotherGerrit](https://community.zammad.org/u/YetAnotherGerrit)
#### Post date: [October 6, 2026, 11:14am UTC](https://community.zammad.org/t/correlate-unchanged-system-emails-into-one-ticket-using-configurable-rules-and-a-time-window/21317/2 "2026-10-06T11:14:45Z")
There are existing integrations for Icinga, Monit, Nagios and Checkmk that do exactly that. Which system do you use?