Major incident management
Quick answer
Promote, communicate and review major incidents with the shipped MIM process.
Key takeaways
- Promotion is a controlled step, not a checkbox anyone ticks
- The workbench centralises updates, tasks and child incidents
- Root cause belongs in a problem record
- Review actions need owners and dates or they evaporate
Promotion
A candidate is proposed by an ITIL user or triggered by criteria, then a major incident manager promotes or rejects it. Promotion sets the major incident flag, opens the communication tooling and starts the timeline that the post incident review depends on.
Communication
The workbench gives one place for status updates, tasks and the child incident list. Communication plans define who receives updates and how often, which stops the ad hoc mail storm that usually accompanies an outage.
After the event
Post incident review is where the value is.
- Link child incidents so impact is measurable
- Record the timeline as it happens, not from memory afterwards
- Create a problem record for root cause, keep it separate from the incident
- Track the actions from the review as change or problem tasks so they actually land
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
What links user impact to a major incident?
- A. Child incidents
- B. Problem tasks
- C. Change requests
- D. Knowledge articles
Show answer
A. Child incidents
Related child incidents show how many users were affected.
Where does root cause analysis belong?
- A. The incident
- B. A problem record
- C. The change record
- D. The post incident email
Show answer
B. A problem record
Problem management owns root cause so incidents can close on restoration.