Source: https://manu-tests-all-orgs.docs-staging.pageloop.ai/product/incidents-problems/major-incident-management # Major incident management A major incident is an unplanned event, such as a network outage, a printer malfunction, or an app failure, that causes significant disruption to business operations, often affecting a large number of users or critical systems. Triaging and resolving these incidents requires early diagnosis and coordinated efforts. To manage these incidents, Atomicwork can: - Cluster similar incidents with AI and surface proposed major incidents for review - Let agents manually propose major incidents from incident forms or by promoting existing incidents - Let workspace and org admins create, approve or decline proposed major incidents - Link related child requests and incidents automatically when applicable - Make major incidents searchable, filterable, reportable, and available in workflows and SLA policies Here's a video walkthrough of how major incident management works in Atomicwork: Your role determines what you can do across the major incident flow: | **Role** | **What they can do** | **Workspace agent** | - Propose a major incident from an incident form - Promote/demote an existing incident to a major incident - Track proposals in the **Proposed by Me** view All proposals go to admins for acknowledgement before becoming major incidents. | **Workspace admin / Org admin** | - Configure major incident detection settings - Approve or decline proposals from agents and from automatic detection - Create major incidents directly without an acknowledgement flow | **Employees** | - Receive broadcast updates when a major incident affects them. Employees cannot create or propose a major incident. ## Configuring major incident detection Major incidents can be detected automatically using configurable thresholds for sensitivity, volume, and time window. This is one-time setup done by an admin. - Navigate to **Settings > Your IT Workspace > General**. - Click the **Requests** tab, then click **Configure**. - Choose your **sensitivity mode**: - **Strict** — only groups incidents that are nearly identical. Ideal for reducing noise. - **Neutral** (default) — groups incidents with the same root problem, even if worded differently. - **Broad** — groups incidents with loose or partial similarities. Shows more matches. - Choose your **alert settings**: - The **number of incidents** that trigger a major incident proposal. Minimum 5, maximum 100. - The **time interval** for incident escalation. Minimum 5 minutes, maximum 60 minutes. - Choose the **notification destination** — how workspace admins are alerted when a potential major incident is detected: - Send a DM to each workspace admin. - Post a message to a public channel in Microsoft Teams or Slack. **Note:** If you don't want Atomicwork to automatically cluster related incidents, toggle the **Group similar incidents** setting off. ## Creating a major incident There are three ways a major incident can be created. ### Automatically through AI clustering When the number of similar incidents within the configured time window crosses your threshold, Atomicwork groups them and sends an acknowledgement to workspace admins for review. Admins approve or decline the proposal from the **Acknowledgements** view or directly inside the Slack or Microsoft Teams notification. Approved proposals create the major incident; declined proposals are removed from the pending queue. ### As a workspace agent Workspace agents have two paths to propose a major incident: - Enable the **major incident toggle** when raising a new incident on any incident form. The **Major incident toggle on incident forms** is only visible to workspace agents and admins — employees don't see it. - Promote an existing incident to a major incident from the incident details page. Both paths trigger the acknowledgement flow — the proposal goes to workspace admins for approval before becoming a major incident. ### As a workspace admin or org admin Workspace and org admins create major incidents directly, without an acknowledgement flow. Use the same major incident toggle on the incident form, or promote an existing incident — either action creates the major incident immediately. ## Reviewing and acknowledging proposals Workspace admins use the **Acknowledgements** view to review pending and completed major incident proposals. - **Approve** a proposal to create the major incident. - **Decline** a proposal to dismiss it. Declined proposals are removed from the pending queue. Approve and decline actions are also available directly inside the Slack or Microsoft Teams acknowledgement notification, so admins can act without leaving their chat tool. ## Tracking your proposals Workspace agents can use the **Proposed by Me** view to track the status of major incidents they have proposed — pending, approved, or declined. ## Working on a major incident To find major incidents in the queue: - Navigate to **Your IT Workspace > Requests** and open the **Incidents** view. - To see only major incidents, apply the major incident filter. Save it as a custom view if you'll use it often. Each major incident shows the number of linked incidents next to it. - Click through to a major incident to see all linked incidents. **Unlink an incorrectly linked incident.** From the major incident's linked incidents list, you can manually unlink any incident that you feel has been incorrectly grouped. **Configure how new related incidents are handled.** On the major incident, click **Manage** to: - Toggle **Link new incidents** on to automatically link related incoming incidents to this primary incident for 24 hours. - Set a predefined message that's sent as an automatic first response to any new incident that gets detected and linked. ## Promoting and demoting incidents Any standard incident can be promoted to a major incident, and any major incident can be demoted back to a standard incident. - **Promotion** by a workspace agent triggers the acknowledgement flow for admin approval. Promotion by a workspace or org admin happens immediately. - **Demotion** changes the ticket type from major incident back to standard incident. Child incidents that were linked stay linked — nothing is unlinked. SLAs are recomputed and the change is captured in the audit trail. ## Communicating with employees Send status updates to all requesters affected by a major incident by broadcasting from the major incident itself. Toggle the **Broadcast message** option on when responding, and your update goes to the requesters of all linked child incidents and requests. ## Managing linked incidents in bulk You can update certain attributes across all incidents linked to a major incident at once: - From the major incident's linked incidents list, select the requests you want to update — or click **Select All** in the bottom modal to update every linked incident. - You can change the **status**, **assignee**, **category**, and **subcategory** in bulk. ## Using major incidents in workflows, SLAs, and analytics Major incidents are globally searchable and can be analyzed separately in Performance Analytics. The **Major incident enabled** filter is available in: - Request views — to build saved views of major incidents only. - Custom workflows — as a filter condition, and as an action to update a request's major incident status. - SLA policies — to apply different SLAs to major incidents. - Reporting and analytics — to slice metrics by major vs standard incidents. ## Notifications and audit trail Major incident actions generate notifications across Slack, Microsoft Teams, and email, with actor attribution and action buttons where applicable. The audit trail captures every lifecycle event: - Acknowledgement decisions (approve and decline) - Promotion and demotion - Linking and unlinking of incidents - Status changes