Skip to main content
Incident management is how you handle service disruptions in Serval. Use an Incident ticket to track and resolve a single issue, and a Major Incident ticket to coordinate a widespread disruption by keeping every affected ticket connected to it. Serval does three things automatically to keep this manageable: it groups related incidents under one report, it detects when an incident looks like a major incident, and it links new reports to an active major incident. Each is described below.

​
When to Use an Incident Ticket

Use an Incident ticket when normal service is not working and your goal is restoration rather than fulfillment. Common examples include VPN outages, SSO failures, email sync issues, and critical integrations timing out.
Use a Request ticket for fulfillment work, such as access, equipment, or standard service asks.

​
When to Use a Major Incident

Use a Major Incident when one issue is affecting many people at once and needs a coordinated response, so their individual tickets can be tracked and updated together. Common examples include a company-wide VPN outage, an identity provider (SSO) going down, or a core application being unavailable for everyone on the team.
When several people report the same underlying issue, Serval’s AI Help Desk Agent recognizes that the new incidents are related and links them together, so your team sees one cluster instead of a pile of disconnected tickets.
  • Everything links under the first report. The earliest-created incident of the cluster becomes the anchor, and every related incident links to it. This anchor is stable — as more reports arrive, they attach to the same original incident rather than creating a competing group.
  • The cluster is a star, not a chain. Related incidents link to the anchor, not to one another, so there is always a single ticket that represents the group.
  • Only open incidents count. Resolved or canceled incidents are not pulled into a cluster.
Grouping is about relatedness — it does not by itself decide that the issue is major. A cluster can stay a set of linked incidents, or it can be promoted to a major incident (manually or automatically) when the scope warrants it.
Grouping runs on incidents specifically. A ticket is grouped after Serval classifies it as an Incident, so grouping always operates on the correct, post-classification ticket type.

​
Promoting an Incident to a Major Incident

Promotion turns an incident into the coordinating Major Incident for a widespread issue. In Serval this is not a silent type flip — it runs an installed, configurable “Promote to Major Incident” workflow so promotion can be governed, approved, and audited like any other change.

​
Install Major Incident First

Major Incident is an opt-in ticket type. A team manager installs it from Team Settings → Ticket Types → Major Incident. The install dialog collects two things and seeds the type in one shot:
  • Statuses — a dedicated status lifecycle for major incidents (see Major Incident Statuses below), pre-filled with a suggested set you can edit.
  • Promotion approvers (optional) — approvers who must sign off before a promotion completes. Leave it empty to promote with no approval.
Installing seeds the major-incident status pool and model and installs the Incident Promotion workflow — a team-only workflow placed in an Incident Management folder and restricted to the team’s managers.
Install is a one-time action. After installing, you edit the model, statuses, approvers, and workflow directly — reinstalling is blocked so it never overwrites your team’s later changes.

​
Configuring the Promotion Workflow

Promotion is powered by an ordinary Serval workflow, so you configure it the way you configure any other workflow — this is what makes promotion governable. On the Major Incident tab (Team Settings → Ticket Types → Major Incident) you’ll see the Incident Promotion workflow card once the type is installed. From there:
  • Edit workflow opens it in the Workflows editor. Add an approval step, notifications, or any other steps your process needs. The card summarizes the contract: the workflow runs when an incident is promoted, and the promotion takes effect when the workflow completes.
  • Because promotion only reclassifies the ticket after the workflow finishes, an approval step in the workflow is a hard gate — the incident does not become a major incident until approvers sign off.
  • If you installed the type before the workflow existed, the tab shows an Add promotion workflow prompt to finish setup without touching your existing statuses and fields.
The same Incident Promotion workflow runs for both manual promotions and automatic detection. Configure approvals once, and every promotion — however it was triggered — goes through the same gate and audit trail.

​
Promote Manually

A manager opens the incident’s actions menu and chooses Promote to major incident. You can optionally record a reason, which appears inline on the type-change entry in the activity log. Promotion keeps the ticket’s existing custom-field values and moves it into the major-incident status set, starting at that set’s initial status. Behind the scenes this starts the promotion workflow rather than flipping the type directly. If an approval procedure is configured, the promotion waits for approver sign-off before the ticket is reclassified.

​
Who Can Promote, and Approvals

Two independent controls decide who is involved: So “who can propose a promotion” and “who must approve it” are separate: you can let managers trigger promotions while still requiring, say, an on-call lead or an incident commander to approve before the change takes effect. Because promotion runs through a standard workflow, its approval, notifications, and audit trail behave like any other Serval workflow.
A promotion is refused if one is already in progress for the incident, if the incident has another required workflow still pending, or if the incident is not eligible (for example, it is not an incident type). These surface as clear errors so nothing is silently superseded.

​
Automatic Major-Incident Detection

Once Major Incident is installed, Serval continuously evaluates whether an incident should become a major incident and proposes promotion for you — you do not have to build your own detection workflow.

​
When Detection Runs

An incident is (re)assessed whenever a signal that could change its severity changes:
  • It is created as, or reclassified to, an Incident.
  • Its priority is raised.
  • Its affected-service blast radius is (re)computed — for example, when a Tier-1 service is pulled into the set of impacted systems.
Because assessment re-runs when priority is raised, an incident that starts low and escalates isn’t missed — it becomes eligible the moment it crosses the priority threshold.

​
How Serval Decides

Detection is deliberately about the nature of what’s affected, not a raw ticket count:
  1. Priority pre-gate. Priority is how Serval captures an incident’s impact and urgency (in ITIL terms, priority = impact × urgency), so it’s the first thing the pre-gate checks. Only incidents at High priority or above are evaluated further — by default that means High and Critical — so Medium- and Low-priority incidents are skipped cheaply. The gate is based on the priority’s rank, not its name, so it keeps working even if your team renames its priority levels.
  2. Scope and criticality judgment. Serval weighs the Configuration Items the incident affects — their type and criticality tier — plus the blast radius reached through service dependencies. A single incident that takes down one Tier-1 business service can qualify on its own, while many reports about individual laptops or personal accounts will not. Serval can infer criticality even when a tier isn’t explicitly set.
  3. Promote the right ticket. If the incident belongs to a cluster, detection promotes the cluster’s anchor (the first report), not a member — so the group gets one coordinating major incident.

​
What Makes an Outage a Major Incident

Serval uses the definition ITIL and ServiceNow share: a major incident is the highest-priority incident — high impact combined with high urgency (ITIL Priority 1), causing significant business disruption and warranting a dedicated, coordinated response. A localized, low-severity, or routine issue is not a major incident, and when the evidence is thin or the call is borderline, Serval does not promote. To make that judgment, Serval weighs all the evidence on the incident:
  • The affected Configuration Items (CIs). Their type, name, and criticality tier when set (tier_1 = revenue- or safety-critical). Serval infers criticality from the CI’s name, type, and the incident text even when no tier is set — a shared production system, business-critical service, or vital business function reads as high impact, while a single low-criticality item like a personal device or individual account does not, even in numbers.
  • The incident itself. Its title and description — what is broken, how widely, and for whom.
  • Blast radius. How many downstream services sit in the affected CIs’ dependency graph. A larger blast radius supports breadth, but is not required — one critical service down can be major on its own.
  • Urgency. Whether the damage is escalating or time-sensitive, or an SLA is breached or about to be. The ticket’s priority is your team’s own urgency/impact signal and feeds this.
  • Severity & recovery. A complete outage versus a minor or cosmetic degradation; whether there’s no known workaround or the recovery time is unknown.
  • Exposure. Material financial, reputational, regulatory/compliance, data-privacy, security, or safety exposure.
Serval promotes only when the incident is clearly both high-impact and high-urgency, and it returns a short reasoning that names the specific CIs and factors behind the call — which is exactly the reason recorded on the activity log.
This is why the affected CIs matter so much: “one affected item” can be a company-wide identity provider or a single laptop. Serval judges the nature of what’s affected, not the count — so keeping incidents’ affected services accurate directly improves detection quality.

​
Detection Proposes; People Approve

When an incident qualifies, Serval starts the same approval-gated promotion workflow used for manual promotion. Automatic detection therefore proposes a major incident — if you configured an approval procedure, an approver still signs off before the ticket is reclassified. Serval also records a user-facing reason on the anchor ticket’s activity log explaining why it was proposed (its priority and the services it affects). Detection is careful not to nag:
  • It never assesses or promotes a resolved or canceled incident.
  • It never re-proposes a promotion a person already acted on — if an approver denied a proposal, a later priority edit or blast-radius change won’t ask them again. A human can still promote manually at any time.
Automatic detection is a safety net, not a replacement for judgment. Managers can always promote manually, and approvals keep a human in the loop before any incident becomes a major incident.

​
Major Incident Statuses

Major incidents use their own status lifecycle instead of the generic To Do / In Progress / Done set, so the response tracks its real stages, such as Declared, Investigating, Mitigating, Monitoring, and Resolved. Configure these on the Major Incidents tab under Team Settings → Statuses, where you can add and edit statuses. Promoting an incident to a major incident moves it into the major-incident status set, starting at that set’s initial status.

​
How Incident Management Works in Serval

1

Incident is created and typed

A ticket comes in from Slack, Teams, email, web, or external sync. Serval can classify it as an Incident.
2

Related reports are grouped

Serval’s AI links related incidents under the earliest-created report (the anchor), so duplicate reports of the same issue are tracked as one cluster. See Grouping Related Incidents.
3

Team triages and routes

Your team sets status, priority, assignee, labels, and due date to establish ownership and urgency.
4

A major incident is proposed or declared

For a widespread issue, a major incident coordinates the response. A manager can promote manually, or Serval’s automatic detection proposes promotion when an incident’s scope and criticality warrant it. Either path runs the approval-gated promotion workflow, so an approver can sign off first.
5

Serval links related tickets to the major incident

Once a major incident exists, Serval automatically links new related tickets on the same team to it and notifies those requesters that a major incident is underway.
6

Incident is resolved and updates propagate

Your team runs remediation actions (including workflows), resolves the incident, and syncs updates across connected systems when configured. Updates on a major incident flow out to every linked ticket, and resolving the major incident closes the linked reports it was coordinating.
Serval links related tickets automatically: its AI Help Desk Agent detects when a new ticket appears related to an active major incident, links it, and tells the requester in-thread that one already exists. Team members can also link a ticket manually from its Linked Tickets panel.
Related tickets link to a major incident, not to one another. The major incident is the one ticket that every related report connects to; those reports are not linked to each other.
Because every link points at the major incident, updating or resolving that one ticket is how you reach everyone who reported the issue. As a major incident changes, Serval surfaces its updates in each linked ticket’s conversation, so requesters see the update wherever their ticket originated, such as Slack or Teams. Team members can also click the broadcast button (the megaphone) on a major incident’s message composer to push a single status update to every linked ticket at once.