Recurring Issues
Bring incident history into accountable prevention work.
Recurring IssuesBring incident history into accountable prevention work.
Root-Cause InvestigationTrack analysis and the responsible problem owner.
Known ErrorsPreserve known-error context for service teams.
Operational KnowledgeConnect prevention work with useful articles.
HistoryCause
Connect problem records, incident history, known errors and operational knowledge.
What Connects Here
Explore in detailRoot-Cause Investigation
Track analysis and the responsible problem owner.
Known Errors
Preserve known-error context for service teams.
Operational Knowledge
Connect prevention work with useful articles.
History → Cause → Prevention
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.
Knowledge bases
Organize the knowledge available to your organization.
Article records
Maintain governed operational knowledge.
CI inventory
Maintain typed classes and canonical configuration records.
Dependency maps
Traverse recorded relationships and location ancestry.
Actual product view
Inside Problem 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 / serviceKnowledge Management
Manage knowledge bases, categories and external sources, and make knowledge available to service teams and portal users.
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
Problem managers,Service reliability leads,Knowledge owners
Restoring a service does not explain why similar incidents keep returning. Teams need to connect recurring incident context, problem ownership, root-cause investigation and known-error knowledge while keeping longer-term prevention work separate from the immediate responsibility to restore service during an interruption.
Illustrative walkthrough
Illustrative workflow: turn recurring incident evidence into prevention work
An illustrative service team sees repeated incidents associated with the same operational area. The problem owner reviews the available incident and configuration context, records the investigation and known-error information, then relates any proposed preventive work to the appropriate knowledge or governed change process.
01Collect the recurring service context
Review the incidents and affected service or configuration records that justify a problem investigation. Distinguish observed recurrence from an assumed common cause. Identify the accountable problem owner and the information still needed before describing a pattern as a confirmed explanation of the repeated interruptions.
02Investigate and preserve useful knowledge
Use the problem record to retain root-cause work and known-error context with the relevant incident and configuration relationships. Review knowledge that can support responders while investigation continues. Keep uncertain findings qualified so helpful guidance does not become an unsupported claim that the underlying cause has already been eliminated.
03Coordinate accountable prevention work
Relate the investigation outcome to knowledge updates and any appropriate change process. Preserve the responsibilities for review and subsequent work rather than closing every related record together. Evaluate whether the team can explain the prevention decision, supporting evidence and remaining uncertainty after the immediate incidents have been restored.
Inspect the relationship between recurring incident evidence, the problem investigation, known-error context and subsequent work. This supports a credible prevention conversation without equating incident restoration, a suspected cause or a knowledge article with permanent removal of the underlying issue.
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 recurring incident history
- Affected service and configuration context
- Problem owner and knowledge review responsibilities
Candidate measures to agree
- Problem investigations linked to relevant incidents
- Known-error information with accountable ownership
- Preventive work retaining investigation evidence
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.
Is problem management another name for incident resolution?
No. Incident work focuses on responding to and restoring an interrupted service, while problem work investigates recurring issues, causes and known errors. Evaluate how the records connect without removing their separate owners, evidence requirements and longer-term prevention responsibilities after the immediate service has been restored.
Can knowledge help before the root cause is confirmed?
Relevant knowledge can support responders when its scope and uncertainty are clear. Review the article, access and known-error context alongside the investigation. Useful guidance should not be presented as conclusive root-cause evidence or a guarantee that the recurring condition has been permanently removed.
How should a proposed fix enter the operating process?
Where investigation leads to planned technical work, evaluate the relevant change process, review responsibility and affected service context. The problem record should retain the reasoning and evidence while the subsequent work follows its own configured governance rather than treating a proposed fix as automatically approved execution.
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.