Alerts and reporting
When a cluster crosses the Active threshold, the agent and the Problem Manager start seeing it. This page covers what they see, what they can do with it, and what gets created when they decide to act.
Inline banner
A small banner appears at the top of every ticket that belongs to an Active cluster. The agent opens a ticket as usual and sees, above the ticket details:
This looks related to 12 other tickets about email delivery in the last 3 hours. [View Cluster] [Dismiss]
View Cluster opens the cluster's detail page showing every member incident, the AI-generated summary, the growth chart, and the report actions. Dismiss removes the banner from this ticket only (it stays on the other member tickets) and feeds back into the AI as a negative signal.
The banner shows up only on Active clusters, not on Emerging ones. A pattern in the Emerging state is still being evaluated; it would create banner fatigue if every probable false-positive interrupted agents.
Major Incident broadcast
When a Service Desk Agent confirms a cluster as a Major Incident (optionally with MI Commander approval), the agent broadcasts two kinds of notifications:
Queue broadcast. Agents whose queue contains any impacted ticket get:
There is a major incident reported in your queue: "The email server is down." [View now] [Dismiss]
Ticket-level broadcast. Agents whose individually-assigned tickets are part of the cluster get:
There is a major incident reported that impacts the following 2 tickets assigned to you: • Ticket Subject 1 → • Ticket Subject 2 → [View Major Incident] [Dismiss]
The two notifications carry different urgency. The queue broadcast is informational ("you should know"). The ticket-level broadcast is actionable ("update these specific customers"). Each is sent once per MI declaration and does not re-fire when the same cluster grows further.
Human-in-the-loop choice
From the cluster detail page (reached from the inline banner or from the Problem / Major Incident / Change Management Dashboard), the agent has three options:
| Choice | What happens | Feedback signal |
|---|---|---|
| Dismiss | The cluster moves out of the Active surface for this agent. It remains visible on the Problem Manager dashboard for review. | Negative - the AI down-weights similar clustering in the future |
| Report as Major Incident | A draft MI record is created with linked incidents, an auto-generated summary, and a suggested priority based on cluster size, affected users, and business-service impact. The agent reviews and publishes. | Positive - the AI up-weights similar clustering |
| Report as Problem | A draft Problem record is created with the same auto-fills plus a pre-populated RCA template. The agent reviews and publishes. | Positive |
The draft is fully editable before publishing. Nothing leaves the agent's screen until Publish is clicked. The "Report as MI" path may route through an approval queue if the tenant has MI Commander review enabled.
Suggested priority and risk score
When the AI drafts a Problem or MI record, it suggests a priority and risk score based on:
- Number of linked incidents
- Affected user count
- Business-service impact of the affected services
The priority is a suggestion; the agent can override before publishing. The risk score keeps updating dynamically as new incidents join the cluster while the record is still open, so by the time the agent reviews the draft, the numbers reflect the latest state.
Pre-populated RCA template
When the AI drafts a Problem record, the RCA template is pre-filled with everything the system already knows. The judgment fields are left blank because they are the human's job.
| Field | Pre-filled? |
|---|---|
| Problem Statement | Yes - from the cluster summary |
| Detection Date / Time | Yes - earliest incident in the cluster |
| Business Impact | Yes - incident count plus detail |
| Affected Services / CIs | Yes - parsed from incident details |
| Known Error Reference | Yes - if a KEDB match exists |
| Root Cause / Contributing Factors | Blank |
| Resolution Description | Blank (filled after resolution) |
| Problem Resolution Date / Time | Auto, from status transitions |
| Known Error Record Created | Blank (filled after resolution) |
The template structure itself is configurable per tenant. See Configuration.
Feedback loop
Every Dismiss and every Report action is a signal. The aggregate of those signals is shown on the dashboard as a precision metric: what percentage of clusters lead to an actual MI or Problem record? Over time, this metric tunes the per-tenant similarity threshold to fit the tenant's tolerance for noise versus missed patterns.
The user-facing tuning is automatic. Tenants who want explicit control can override the auto-tuned threshold from the Configuration page.
Related topics
- Incident clustering - how clusters form before they trigger an alert
- Problem / Major Incident / Change Management Dashboard - the Problem Manager view
- Known Error Database - where past resolutions get re-used