Major Incident War Room
When the AI confirms a Major Incident, the response can't wait on someone manually convening a war room. Major Incident War Room is the autonomous step that closes the gap: a Microsoft Teams or Slack channel is created without human action, the right responders are added, and the channel opens with the cluster summary, impacted scope, and live status already in it. Responders walk into a workspace instead of a notification.
When it fires
The war room is triggered by the same engine that runs the rest of Problem and Major Incident Detection: real-time case-cluster analysis on incoming tickets (incident clustering) detects an emerging pattern that the engine classifies as Major-Incident-grade.
If the tenant has configured an MI Commander approval step (described on the Configuration page), the war room opens once the commander confirms. Without that step, the war room opens immediately on detection.
Who gets added
The audience is added per pre-configured rules. The default rules include five roles:
| Role | Source |
|---|---|
| Incident Commander | The on-call commander from the tenant's MI rota |
| Resolver groups | Group memberships encode skill alignment - the engine picks the groups whose members have the right skills for the impacted services |
| Service owners | Pulled from CI / service ownership data in the CMDB so the people accountable for the impacted services are in the room |
| Business stakeholders | The stakeholder list configured for the affected business service |
| Communications team | The comms responders who handle external and internal stakeholder updates |
Tenants can edit which rules fire, add custom rules, and override the channel platform (Teams vs Slack) per severity level. Detail on the Configuration page.
What's pre-populated
When responders open the channel, the first messages contain:
- Cluster summary - the AI-generated description of what's in common across the linked incidents and when the cluster started
- Impacted scope - affected services and CIs, an estimated affected-user count drawn from incident metadata and DEX signals
- Live status - the most recent state of the underlying MI record (Reported, Under Investigation, Partially Restored, etc.), pinned and updated as the status changes
- Linked incidents - the list of member tickets the cluster is built from, each as a clickable reference
The channel becomes the working space for the response. Status updates inside the channel feed back into the MI record; updates to the MI record reflect in the channel.
How it differs from MI broadcast notifications
The two surfaces serve different audiences and intents.
| Surface | What it is | Audience |
|---|---|---|
| MI broadcast notifications | Popup alerts on the inbox and on impacted tickets | Service Desk Agents whose queues or tickets are affected |
| War Room | A dedicated channel for the response team | Incident Commander, resolver groups, service owners, stakeholders, comms |
Both fire from the same MI declaration. The broadcast tells frontline agents what's happening to their tickets. The war room is where the team coordinating the fix actually works.
How it differs from Huddle
Huddle is the agent-initiated swarm room for a single high-risk ticket. The War Room is the engine-initiated room for an MI that spans many tickets. The key differences:
| Question | Huddle | War Room |
|---|---|---|
| What triggers it? | An agent picks up a matching ticket | The AI detects an MI-grade cluster |
| Who decides to open it? | Agent (one-click) or auto per tenant config | The engine, optionally gated by MI Commander approval |
| Scope | One ticket | An entire cluster, plus the wider impacted scope |
| Audience | Experts derived from past similar resolutions plus admin-configured pools | Five role-based audiences pulled from the MI rota, CMDB, and service-ownership data |
A Huddle that grows into a Major Incident does not transition into a War Room automatically. Once the MI is declared, the War Room opens fresh with its own audience and pre-populated context.
What the War Room does not do
- It does not replace the MI record. The MI ticket remains the system of record; the channel is a workspace for the conversation.
- It does not auto-close. The channel stays open after the MI is resolved so the team can run a debrief or PIR; closing is a manual step.
- It does not page anyone beyond the configured audience. Tenants that need a wider notification fan-out still rely on the broadcast notifications.
Related topics
- Alerts and reporting - the popup-level broadcast that runs alongside the War Room
- Incident clustering - the engine that detects the MI in the first place
- Huddle - the one-ticket equivalent
- Configuration - audience rules, platform overrides, severity gates