Incident Workflows
Coordinate investigation, assignment, priority and technical restoration.
Incident WorkflowsCoordinate investigation, assignment, priority and technical restoration.
Major IncidentsTrack major incident coordination alongside ordinary service work.
Change GovernanceConnect CAB schedules, blackout windows, templates and the change calendar.
Service CatalogGive users a structured path to request available services and tools.
IntakeOwnership
Connect incident, problem, change, request and knowledge records to service levels and the portal.
What Connects Here
Explore in detailMajor Incidents
Track major incident coordination alongside ordinary service work.
Change Governance
Connect CAB schedules, blackout windows, templates and the change calendar.
Service Catalog
Give users a structured path to request available services and tools.
Intake → Ownership → Resolution
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 workflows
Coordinate investigation, assignment, priority and technical restoration.
Major incidents
Track major incident coordination alongside ordinary service work.
Change governance
Connect CAB schedules, blackout windows, templates and the change calendar.
Service catalog
Give users a structured path to request available services and tools.
Knowledge
Organize knowledge bases, categories, articles and configured external sources.
Business calendars
Apply configured working-time calendars to supported service commitments.
Actual product view
Inside Service Workflow Foundation.
See the running demo environment. Features and records are subject to your role, configuration and integrations.
Connected by design
Context travels
with the work.
Service records, configuration items, people, locations and evidence share the same operational foundation. Move from investigation to the related asset, service or customer workflow with clear ownership.
Explore the platform architectureImplementation 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
Service architects, process owners, platform administrators and ITSM implementation teams
Service processes become inconsistent when incidents, changes and requests use different definitions for ownership, service context and working time. A common workflow foundation must connect those records without erasing their distinct purposes or approval requirements.
Illustrative walkthrough
Design a connected service process before expanding rollout
A fictional implementation team designs an employee access service. It connects catalog intake and fulfillment with incident handling, knowledge and change governance, then tests the business calendar and role responsibilities before expanding to other service processes.
01Define the service record paths
Distinguish catalog requests, incidents, major incidents and problem work, then identify the roles and service context each path needs to progress responsibly. Coordinate investigation, assignment, priority and technical restoration.
02Connect governance and knowledge
Review CAB schedules, blackout windows and change templates alongside the knowledge bases and categories that should support the chosen service workflow. Connect CAB schedules, blackout windows, templates and the change calendar.
03Test calendars and user intake
Use the portal to exercise the request path, then inspect the configured business calendar and supported response or resolution rules with the process owner. Organize knowledge bases, categories, articles and configured external sources.
The implementation walkthrough should show how a request differs from an incident, how a proposed change reaches its review gate and which working-time calendar applies to the selected commitment. Use demonstration records and preserve the applicable reporting scope.
Explore the platform
See Qintorava in action.
Open a workspace for a closer look.
Prepare the evaluation
Bring the right inputs.
What to prepare
- Service process and record definitions
- Change calendar and approval responsibilities
- Catalog item and business calendar
Candidate measures to agree
- Service paths with defined ownership
- Change scenarios tested against governance rules
- Commitment rules verified with process owners
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.
Why distinguish requests from incidents?
Request fulfillment and technical restoration serve different purposes, so the shared foundation connects their context while preserving the record type, ownership and applicable workflow responsibilities.
Can process owners configure working-time expectations?
The available foundation applies configured business calendars to supported commitments, and implementation should verify the relevant working hours and timing behavior with the accountable service owner.
Does the foundation remove CAB or blackout controls?
No. Change governance includes CAB schedules, blackout windows, standard templates and the organization change calendar, which should be demonstrated in the selected process design.
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.