Major Incident Management

Overview

When a major incident occurs, Xurrent provides a unified workspace that spans both the ITSM component and IMR (Incident Management and Response). Rather than managing the incident in one system and tracking it in another, both records are created together, stay synchronized throughout the incident lifecycle, and feed into the same post-incident review process.

This article explains how the two platform components connect during a major incident: what gets created, what stays in sync, how teams navigate between them, and how post-incident work flows back into ITSM.

How a Major Incident Starts

A major incident can originate from either side of the platform. Regardless of the entry point, the result is the same: a linked pair of records, one in IMR (the operational workspace) and one in ITSM (the service record), kept in sync throughout the lifecycle.

Starting from an alert (IMR-initiated)

When monitoring and observability tools detect an issue, alerts flow into Xurrent IMR. AI-powered correlation groups related alerts, suppresses duplicates, and surfaces the signals that require human attention. When an incident is declared (either automatically based on severity thresholds or manually by a responder), IMR creates the incident and automatically generates a linked request in Xurrent ITSM. The ITSM request appears in the IMR incident's Communication section, and the two records are connected from that point forward.

Starting from the service desk (ITSM-initiated)

When a service desk agent identifies that a user-reported issue represents a major incident, they can escalate the request directly into IMR. This triggers the full IMR incident workspace: on-call responders are paged based on the affected service's escalation policy, a war room is created, and the original ITSM request becomes the linked service record. The severity threshold that determines when escalation triggers an IMR incident is configurable in both directions.

Two Records, One Source of Truth

Every major incident produces a pair of linked records. Each serves a distinct purpose, and both stay current throughout the incident.

The linked ITSM request is visible directly in the IMR incident's Communication section (alongside the Slack or Teams war room link), so responders can navigate to the service record with a single click. Service desk agents working in ITSM can see the linked IMR incident and follow along with live status updates.

What Stays in Sync

The integration between IMR and ITSM is configured as an outgoing integration on the IMR side, connected at the account level via OAuth. It supports three sync directions: IMR to ITSM, ITSM to IMR, or bidirectional. In bidirectional mode, changes on either side are reflected automatically on the other.

Incident Field Mapping

When an IMR incident creates or updates a linked ITSM request (and vice versa), the following fields are mapped:

Status Mapping

Incident status is synchronized automatically using a fixed mapping. This mapping is not configurable because the status values in ITSM are fixed:

When an IMR incident moves from Triggered to Acknowledged, the linked ITSM request moves from Assigned to Accepted. When the incident is Resolved in IMR, the ITSM request is Completed with the completion reason set to "Solved." The reverse is also true: status changes in ITSM are reflected back in IMR.

SLA Tracking

SLA policies defined in IMR (e.g., Critical SLA Policy) run against the incident independently. The ITSM request tracks SLA compliance against its own service level agreements. Breach status is visible on both sides.

Incident Workspace Fan-Out

When a major incident is declared, the IMR workspace fans out across the communication and collaboration channels your teams already use. Each channel feeds back into the central incident record, so nothing is lost when the postmortem begins.

Incident Roles

Each incident supports defined roles that can be assigned to specific responders: Incident Commander, Application SME, Networking SME, and any custom roles your organization defines. Roles are visible in the incident's Details tab and ensure clear ownership during active response. Multiple responders can be tagged into the incident and will continue to receive notifications until the incident is acknowledged.

Post-Incident Review and Follow-Up

When the incident resolves, the focus shifts from response to learning and prevention. Xurrent connects the post-incident workflow directly to ITSM so that root cause fixes are tracked, assigned, and completed, not just documented.

AI-Generated Postmortem

Sera AI automatically generates a postmortem report based on the incident timeline, alert data, responder actions, and discussion threads. The postmortem is linked directly from the IMR incident (visible in the Details tab as "Postmortem") and includes root cause analysis, a timeline of events, and recommended follow-up actions.

Post-Incident Tasks as RFCs

Follow-up actions identified in the postmortem are created as Post Incident Tasks in IMR. These tasks flow into Xurrent ITSM as Requests for Change (RFCs), creating a direct link between what was learned during the incident and the remediation work that prevents recurrence.

The RFC mapping follows the same integration pattern as incidents:

RFC status mapping follows a fixed pattern:

Platform Navigation

Xurrent ITSM and IMR are connected through a platform flipper (sometimes called the "waffle") in the toolbar. Users who are authorized in both platforms can switch between them without re-authenticating. The same navigation also provides access to Status Pages.

How it works

The platform flipper uses JWT-based authentication. When a user clicks the IMR icon from within Xurrent ITSM, a signed token is generated containing the user's identity and account information. IMR validates the token and logs the user in automatically. The reverse path (IMR to ITSM) works the same way. Users never see a login screen when moving between platform components.

Account linking

The connection between an Xurrent ITSM account and an IMR account is established during initial setup. A single ITSM directory account maps to a single IMR account. Once linked, all authorized users in that account can navigate between platform components using the flipper.

First-time setup

When a Xurrent ITSM administrator clicks the IMR icon in the platform flipper for the first time, they are guided through provisioning: selecting which users to enable in IMR and completing the onboarding flow. Enterprise customers receive an enterprise-tier IMR account. From that point forward, the flipper provides direct access to IMR for all authorized users. Non-administrator users who click the flipper before IMR has been enabled will see a message directing them to contact their account administrator.

Status Pages navigation

The platform flipper also includes Status Pages. If the status page integration is configured, clicking the Status Pages icon takes you to the public status page. If it is not configured, you are directed to setup documentation. Administrators can access the Status Pages admin portal from the public page.

Integration Setup

The connection between ITSM and IMR is established at the account level using OAuth. This is typically completed during implementation, but the steps are documented here for reference.

Step 1: Configure OAuth in Xurrent ITSM

In Xurrent ITSM, navigate to Settings, then OAuth Applications. Create a new OAuth application named "Zenduty" (the internal name for the IMR integration) with the Client Credentials Grant type. Enable the required scopes: Account (Read), Note (Create, Read), Organization (Read), Person (Read), Problem (Read), Project (Read), Request (Create, Read, Update), Service (Create, Read, Update), Service Instance (Read), Team (Read), Webhook (Create, Read, Update, Delete), and Webhook Policy (Create, Read, Update, Delete). Generate the application and create a token. Copy the Client ID and Client Secret, then note your Account ID from Settings, then Account Overview.

Step 2: Connect in IMR

In Xurrent IMR, navigate to Account, then Connections, then Xurrent. Click Configure and paste the Account ID, Client ID, and Client Secret. Select the correct Region and Environment (Production for live deployments). Click Add to save the connection.

Step 3: Configure the integration per service

Navigate to Teams, then Service, then Integrations, then Add Outgoing Integration. Select Xurrent and choose the tenant you configured in Step 2. Select the ITSM Service Instance to link with the IMR service. Choose the sync direction: ITSM to IMR, IMR to ITSM, or Bidirectional. Optionally enable note sync and configure custom impact mapping (requires at least 4 priorities defined in IMR). Set the default impact for cases where no priority is specified.

Configuration Summary

The following elements are configurable for your organization's major incident workflow:

Related Articles

Xurrent Integration Guide (IMR Setup)

Getting Started with Xurrent IMR

Configuring Escalation Policies and On-Call Schedules

Status Pages: Setup and Configuration

Sera AI: Summarizer, Querier, and Postmortem

Platform Connector: Linking ITSM and IMR Accounts