Running a major incident

A major incident is a crisis: an incident whose impact calls for dedicated coordination, a single lead and regular communication. The Major incidents module of Portail ZAPP frames the crisis, from the declaration to the post-incident review. The screens are open to Service Desk agents, Major incident managers and administrators; Release Managers can open a crisis page (for example after escalating a deployment).

The crisis radar

The Major incident radar menu entry opens the Major incidents page: the crises, with their number, status, Major Incident Manager and affected CIs or services. Filter by text (number, title or ticket), by Status, by Major incident manager or by Affected CI / service; Ongoing limits the list to active crises.

On a ticket, the Ongoing major incident panel tells agents that the ticket is driven by a crisis and links to it.

Declaring a major incident

A major incident is declared from an open incident ticket: Declare a major incident button on the ticket page. The button does not appear if a crisis is already ongoing for that ticket.

The form asks for:

• the Declaration criteria (at least one): wide impact, critical service compromised, urgent restoration without a workaround, financial, regulatory or reputational exposure, cross-team coordination;
• the Major incident manager (MIM), chosen among the members of the Major incident managers group. If that group is empty, add members before declaring;
• the War room link (video call, conference bridge), optional;
• the Title and What is affected;
• the Affected CIs / services: the CIs linked to the ticket are offered, untick those that are not affected. Others can be added from the crisis page.

Declare the major incident opens the crisis page. The designated MIM is notified.

A release can also turn into a crisis: from a release page, a manager can escalate a failed deployment into a major incident. An incident ticket is then created and the crisis declared with the "critical service compromised" criterion.

A single lead

A crisis has only one Major incident manager at a time. Only the MIM in charge and administrators drive the crisis: change the status, fill in the war room link, add or remove CIs, manage stakeholders and send communications.

Reassign, on the crisis page, hands over to another member of the group: the MIM in charge can do it, as can a group member or an administrator taking over a crisis whose MIM is unavailable. The former MIM then loses control; the new one is notified.

Crisis phases

Each status change can carry a comment. It is notified automatically to the internal and customer stakeholders (see below).

The war room

The War room button of the crisis page opens the crisis's shared timeline, updated in real time for everyone who has it open:

• choose the entry's Type (Diagnostic, Decision, Communication, Escalation), write the Message, then Record;
• system Events (status changes, MIM changes…) are added automatically; the filters show everything or a single type;
• Mobilized responders lists the MIM (MIM badge), the declarer and the people who wrote;
• Join the call / bridge opens the war room link.

Any user with access to the crisis can record an entry until it is closed. After closing, the timeline is frozen. The Offline badge signals a lost real-time connection: the page resynchronises when it reconnects.

Communicating with stakeholders

The Stakeholder communications card of the crisis page:

• Stakeholders: add a Group, a User or an External email address, for the Internal or Customers audience;
• to send a message: choose the Audience, write the Message, optionally give the Next update ("in 30 minutes, at 2 pm"), then Send. Suggest the declaration message fills the message with a standard text, to adapt;
• each audience receives the message in its own email template, editable in template administration;
• the Public (recorded) audience is only recorded: there is no public status page yet, nothing is sent.

The Communication history keeps each message, its recipients, the automatic status change notifications and any sending failures.

Post-incident review and closing

Once the service is restored (Resolved status), the MIM in charge (or an administrator) fills in the Post-incident review. The review is "blameless": facts, causes and improvements, never a culprit. It asks for the Root cause summary, the Improvement actions and the The cause is permanently fixed box. It is pre-filled from the timeline's diagnostics and decisions, to be reworded.

To Close, you need:

• a completed review;
• if the cause is not declared permanently fixed, a linked problem that tracks it (unless the Problem management module is not installed).

From the review:

• Create the problem opens a major problem linked to the incident's ticket; Or link an existing problem links it to a problem that is already open;
• Create the emergency change prepares a draft emergency change (affected CIs, ticket, description), approved by the ECAB, to complete and then submit. It is raised during containment or at resolution. Or link an existing change links a change that already exists.

These actions follow your rights on the Changes and Problems modules: if you do not have them, the page invites you to ask an administrator for access.

Dashboard and board

• Major incident dashboard: ongoing crises, time to resolve and resolved crises awaiting review over the period;
• Major incident board: crises by phase. Drag a card to a highlighted column to apply the transition; only the MIM in charge or an administrator can do it. Closing is done from the crisis page. The board requires the Data grids module; without it, use the radar.

The module has no AI feature: it works the same way whether AI is enabled or not.