Understanding Major Incident Management in ServiceNow
Modern businesses run on IT services — applications, cloud platforms, networks, internal systems — all of which need to stay available for employees and customers to keep working without interruption. When something serious breaks, the impact can spread far beyond a single user or component.
Not every incident is created equal. Most can be resolved through the standard incident process, but some affect critical business services, large numbers of users, or key operations — and those need a faster response, tighter coordination, and clearer communication.
That’s exactly where Major Incident Management (MIM) comes in.
What Is Major Incident Management?
MIM is ServiceNow’s structured process for identifying and managing incidents with significant business impact. It extends standard Incident Management with capabilities built specifically for high-impact situations: major incident candidates, trigger rules, on-call scheduling, communication plans, collaboration tools, and dedicated workflows.
In short, MIM helps organizations:
- Respond quickly to high-impact incidents
- Bring the right teams and people together
- Focus on restoring the affected service as fast as possible
What You Need Before Getting Started
You don’t need to be an advanced ServiceNow developer, but a few things will make the learning curve much smoother:
Requirements
- Access to a ServiceNow instance with the Incident Management – Major Incident Management plugin activated
- Appropriate roles/permissions to configure MIM features and administration settings
Helpful skills
- Basic understanding of Incident Management and ITSM processes
- Familiarity with ServiceNow tables, records, users, groups, and navigation
- Working knowledge of Flow Designer and Workflow
- Comfort with conditions, trigger rules, communication plans, on-call schedules, notifications, and assignments
What Does MIM Actually Do?
MIM coordinates people, teams, communication, automation, and on-call support around a single high-impact incident, rather than leaving each team to respond separately. Here are its core capabilities:
- Major Incident Identification — Predefined criteria and Trigger Rules automatically flag incidents that may be significant.
- Major Incident Candidates — A review stage where a potentially serious incident is proposed before officially becoming a Major Incident.
- Major Incident Management — Once accepted, MIM provides a dedicated process to coordinate the response.
- Major Incident Trigger Rules — Automatically identify incidents meeting specific conditions (e.g., affecting a critical service).
- Alert Management Integration — Alerts from Event Management/ITOM can trigger Major Incident Candidates.
- Major Incident Assignment — Routes the incident to the correct Assignment Group and on-call user.
- On-Call Scheduling — Ensures 24×7 coverage through shifts, rosters, rotations, and escalation rules.
- Communication Plans — Define what gets communicated, when, and to whom during a major incident.
- Communication Tasks and Contacts — Individual communication activities and their recipients.
- Collaboration — Teams coordinate via tools like Microsoft Teams while the Major Incident record remains the source of truth.
- Service Operations Workspace — A centralized workspace for managing major incidents and configuring MIM settings.
- Post-Incident Review (PIR) — Structured review of what happened and what can be improved.
Incident vs. Major Incident: What’s the Difference?
| Regular Incident | Major Incident | |
|---|---|---|
| Definition | An unexpected issue that interrupts or reduces an IT service | A serious service disruption with significant business impact |
| Handling | Managed per assigned Priority and SLA | Requires immediate attention to restore service ASAP |
| Ownership | Handled by the assigned support team | Coordinated under MIM, usually led by a Major Incident Manager |
A high-priority incident (e.g., P1) doesn’t automatically become a Major Incident — that depends on business impact and whether a coordinated, cross-team response is required.
The MIM Plugin and Components
- Plugin name: Incident Management – Major Incident Management
- Plugin ID:
com.snc.incident.mim
Activating it also enables Incident Communications Management, Incident Updates, and Task-Outage Relationship (if not already active).
Key modules: Overview, Create Major Incident Candidate, Create Major Incident, Candidates, Open, All — plus Trigger Rules and Properties under Administration.
Key UI Actions: Propose Major Incident, Promote to Major Incident, Reject Major Incident Candidate, Create Major Incident, Demote Major Incident, Preview PIR, Regenerate PIR Timeline, View Workbench.
The Three MIM Personas
- Major Incident Manager — Manages the response team; can promote or demote Major Incidents; configures Major Incident Properties and Trigger Rules.
- Communications Manager — Coordinates and manages stakeholder communication throughout the incident.
- Major Incident Response Team — Performs the technical work to restore the affected service and supports the Major Incident Manager.
Major Incident Candidates: The Review Stage
An incident becomes a candidate either automatically (via a Trigger Rule) or manually (a user selects “Propose Major Incident”).
Once proposed, fields like Major Incident State, Proposed By, Business Impact, and Probable Cause become available for review. The Incident Manager or Major Incident Manager then decides:
- Promote to Major Incident — if MIM is genuinely required
- Reject Major Incident Candidate — if it can stay in the standard incident process
Major Incident Trigger Rules
Instead of relying on someone to spot a serious incident manually, Trigger Rules let ServiceNow evaluate incidents automatically. Configuration includes:
- Name — purpose of the rule
- Table Name — usually Incident
[incident] - Trigger Conditions — what must be true
- Action to Take — e.g., Propose Major Incident
- Active — enabled or not
- Execution Order — evaluation sequence
Rules run asynchronously and only evaluate when the Parent Incident field is empty, the Major Incident State isn’t already Proposed/Accepted, and the incident is Active. Predefined rules ship inactive by default.
Alert Management Rules
These connect ITOM alerts to the MIM process — the counterpart to Trigger Rules, which start from Incidents. A rule is configured across three areas:
- Alert Info — name, active status, order, and multiple-rule behavior
- Alert Filter — the conditions an alert must meet (with a Preview option to test against existing alerts)
- Actions — typically Remediation Subflows, which can run automatically or manually to create a Major Incident Candidate or Major Incident directly
Rules run about 5 seconds after an alert updates (with the timer resetting on further changes) to avoid duplicate actions. An active rule needs both a filter and at least one action — otherwise it’s automatically deactivated.
Major Incident Properties
Found under Incident > Administration > Major Incident Properties, these control core MIM behavior:
- Creation — whether promoting a candidate reuses the existing record or creates a new Major Incident (with the original becoming a child incident)
- Communication/Email — which communication task types can use Compose Email, and default recipient placement (BCC by default)
- Assignment — which group Major Incidents route to via the Major Incident Management Group property
- Fields Copied — which attributes carry over from the child incident (e.g., Service, Configuration Item, Description)
- Post-Incident Review — custom UI page association for exported PIRs
How Major Incident Assignment Works
Assignment depends on the current Assignment Group, the configured MIM Group property, whether On-Call Scheduling is active, and how the record was created:
- If Assignment Group is empty, it’s auto-assigned to the configured MIM group
- If On-Call Scheduling is active (with a defined shift and available user), the incident can go to that on-call person
- On manual promotion, the promoting user can become the new Assigned To
- On direct creation, the creator becomes the Assigned To
- Communication Plans and Tasks inherit assignment from their source Major Incident when their own fields are empty