Priority and Ownership
Coordinate assignment, investigation and restoration.
Priority and OwnershipCoordinate assignment, investigation and restoration.
Affected ConfigurationConnect incidents to CIs and recorded service context.
Events and DependenciesUse alert evidence and saved relationships during response.
Recovery HistoryKeep technical decisions and work history with the record.
PriorityResponse
Bring priority, ownership, affected CIs, operational events and service recovery into incident work.
What Connects Here
Explore in detailAffected Configuration
Connect incidents to CIs and recorded service context.
Events and Dependencies
Use alert evidence and saved relationships during response.
Recovery History
Keep technical decisions and work history with the record.
Priority → Response → Restoration
Explore the details below, then bring your workflow, source data and questions to a guided conversation.
Built into the platform
The capabilities behind
the experience.
Incident and major incident response
Manage priority, assignment, investigation and restoration in connected records.
Problem management
Track recurring issues, root cause and known-error work.
Event workspace
Review operational events in a focused surface.
Alert triage
Track severity, acknowledgment and ownership.
CI inventory
Maintain typed classes and canonical configuration records.
Dependency maps
Traverse recorded relationships and location ancestry.
Actual product view
Inside Incident Management.
See the running demo environment. Features and records are subject to your role, configuration and integrations.
Connected capabilities
Explore the workspaces
that make it possible.
01 / service
IT Service Management
Unite incidents, major incidents, problems, changes and requests with service context, accountable ownership and AI assistance.
Explore 02 / infrastructureEvent Management
Investigate events and alerts with affected CIs, ownership and linked incident evidence.
Explore 03 / infrastructureCMDB & CSDM
Connect typed CIs, dependencies, service portfolios, services and offerings to hardware, software and customer operations.
ExploreImplementation context
Features depend on enabled modules, configured roles, source data and supported integrations. Agree your implementation scope and acceptance criteria during discovery.
Who this is for
Incident commanders,Service desk responders,Infrastructure support teams
Responders can lose time reconstructing context when priority, ownership, affected configuration items and operational signals are disconnected. An effective incident evaluation connects these records while keeping investigation and restoration accountable and distinguishing measured operational evidence from assumptions about the condition of a service.
Illustrative walkthrough
Illustrative workflow: investigate an incident with recorded service context
An illustrative service team receives an incident associated with infrastructure disruption. It reviews priority and assignment, inspects the affected configuration item and related operational events, and follows recorded dependencies before deciding which investigation and recovery work should be owned by each participating team.
01Establish incident responsibility and scope
Review the incident’s priority, assignment and affected service or configuration item. Determine whether major-incident coordination is appropriate to the scenario. Identify the responsible responders and confirm what has actually been reported before treating every related alert or dependency as proof of the same underlying problem.
02Investigate with connected operational context
Inspect associated CI health, recorded dependencies and linked event or alert context. Distinguish measured health from missing measurements, and relate useful evidence to the investigation. Contextual guidance can support review, but the responder remains responsible for the interpretation and the next authorized operational decision.
03Record recovery and follow-up clearly
Maintain the relevant investigation and restoration history with accountable ownership. Relate recurring issues to problem work and planned remedial changes when appropriate. Evaluate the final incident record for source context and unresolved responsibilities rather than assuming that a resolved status proves every contributing issue has been eliminated.
Inspect priority, assignment, affected CIs, related events and restoration history as connected evidence. This helps evaluate responder context and ownership, without guaranteeing a particular recovery time or treating every discovered relationship as a confirmed root cause.
Explore the platform
See Qintorava in action.
Open a workspace for a closer look.
Prepare the evaluation
Bring the right inputs.
What to prepare
- Representative incident and affected configuration item
- Event sources and measured health context
- Responder, service owner and escalation responsibilities
Candidate measures to agree
- Incidents linked to the relevant configuration item
- Investigation records with traceable source context
- Recovery work with clear accountable ownership
These are evaluation criteria, not promised outcomes. Agree the baseline, scope, source coverage and acceptance method with the responsible owners before drawing conclusions.
Questions for this topic
Get the details.
Does an alert automatically establish the incident’s cause?
An alert is evidence to investigate, not a complete explanation. Review the affected configuration item, recorded dependencies, other signals and responder findings before drawing a conclusion. The evaluation should show how relevant events connect to the incident while preserving uncertainty where evidence is incomplete.
How should responders interpret missing health measurements?
An unmeasured configuration item should not be treated as healthy simply because no adverse measurement is displayed. Inspect source coverage and the distinction between measured health states and unavailable information. Include this case in the walkthrough so operational decisions reflect the evidence actually present.
Can recurring incidents connect to problem and change work?
The reviewed service workflows include incident, problem and change management. Evaluate a recurring issue through those related responsibilities, including root-cause investigation and configured change governance. Linking records supports accountability; it does not mean that incident closure automatically completes the longer-term prevention or remedial change process.
Your next operating chapter
See what connects
when everything connects.
Bring one workflow, one service challenge or one part of your estate. We’ll show you where Qintorava fits.