Incident Manager Coordinates a Major Incident

Use Case at a Glance

Persona: An incident manager working with a major incident manager and resolver teams

Job to be done: Escalate a business-critical incident, establish shared operational context, coordinate resolution work, and keep stakeholders informed

Starting point: A high-impact incident in the Agentic IT Service Desk that requires broader attention and coordination

Successful outcome: The incident is classified appropriately, resolver teams restore and verify service, stakeholders receive clear updates, and follow-up work moves to Problem Management.

This use case follows a critical incident from escalation through recovery. It doesn't replace the canonical procedures for proposing, reviewing, promoting, or closing major incidents. Instead, it shows how an incident manager and major incident manager use one record to make decisions, align responders, and preserve an accountable timeline.

Fulfillers can propose an incident as a major incident for review. Users with elevated major incident authority can promote an incident directly from the incident record without approval. Demoting a major incident requires the Major Incident Manager permission. Keep the proposal and direct-promotion paths distinct. See Major Incident Management for IT Services, Review Major Incidents for IT Services, and Demote Major Incidents for IT Services.

Qualify the Disruption

Start with business impact rather than incident priority alone. A major incident affects multiple users or requires an immediate response because multiple business systems are unavailable. Confirm the affected services and users, operational urgency, known dependencies, and evidence from related incidents before escalating.

Use the proposal path when the disruption requires review. Users with elevated major incident authority can use the direct-promotion path when that authority is configured. For qualification and process scope, see Major Incident Management for IT Services.

Establish the Major Incident Record

Record a concise justification that explains the impact, urgency, and reason for broader coordination. A proposal goes to review, where a user with the required authority approves or rejects it. Direct Promote skips the review process. Demote returns a major incident to standard incident handling.

Keep the major incident classification lifecycle separate from the operational incident Status. Proposal, approval or rejection, direct promotion, and demotion are classification actions. Operational Status values such as New, In Progress, Resolved, and Closed describe the incident's progress toward restoration and completion. Use the exact lifecycle state labels documented in Major Incident Lifecycle for IT Services.

Use Major Incident Status Comments to record the reason when demoting a major incident. Record investigation updates on the incident by using its feed, related lists, and operational Status. For canonical state and field behavior, see Major Incident Lifecycle for IT Services. For the review path and optional Problem creation, see Review Major Incidents for IT Services.

Coordinate Restoration and Communication

After classification, use the incident record as the shared operational source. Identify an owner for each recovery action, bring in the required resolver groups, track decisions and dependencies, and verify that associated incidents represent the same disruption.

For complex work, start a configured swarm so that experts collaborate in one channel. Keep material decisions and resolution evidence on the incident record instead of leaving the diagnostic history only in chat. Agentforce can summarize a Slack swarm and post the summary to the record feed. See Swarm on Incidents in Slack for IT Services for the canonical collaboration options.

Send stakeholder updates at meaningful changes, such as acknowledgment, confirmed scope, recovery progress, restoration, and closure. Separate confirmed facts from working hypotheses, state the next expected update, and avoid promising a recovery time without evidence. Configured notifications can deliver updates by email, in-app channels, Slack, or Microsoft Teams. See Notifications for IT Services.

Restore, Close, and Transition

Confirm that service is restored for the affected users and systems before changing the incident to Resolved. Record the restoration action, verification evidence, remaining risk, and any temporary workaround in Resolution Summary. Move the incident to Closed when the lifecycle is complete under the team's process.

Major incident classification doesn't replace follow-up investigation. Transition the event to Problem Management for root-cause analysis and preventive work. Automatic Problem creation occurs only when the corresponding major incident setting is turned on; otherwise, create or associate the required Problem through the team's process.

The adoption milestone occurs when the team moves from fragmented response to one coordinated record: qualified classification, accountable recovery work, consistent communications, verified restoration, and an explicit follow-up owner. For canonical incident resolution and association behavior, see Manage Incidents for IT Services.

Confirm That Major Incident Management Is Ready

Before using this journey as an adoption test, confirm that Incident Management is enabled, the approval group is configured, and users have the permissions required for their assigned tasks. Verify that fulfillers can propose incidents for review, that authorized users can review or directly promote them, and that users who demote major incidents have the Major Incident Manager permission. See Set Up Settings for Major Incidents for IT Services for canonical setup.