How Does Virima Connect ITSM Incident Management to CMDB? A Practical Guide
Connecting incident management to the CMDB is a core ITIL v4 requirement — but in practice, it is one of the most commonly skipped steps in ITSM implementations. Manually linking incidents to CIs is tedious, the CMDB data is often stale, and the value is not obvious until a major incident exposes how much time the team is wasting without it.
Virima 6.1.1 makes the connection automatic. The following questions cover exactly how it works.
How Does Virima Link Incidents to CMDB Configuration Items?
Every incident in Virima 6.1.1 carries a direct link to the CMDB configuration item (CI) involved. This linkage is not a manual lookup — it is built into the incident creation workflow.
When a new incident is created, Virima identifies the affected CI based on the incident source (monitoring alert, user submission, email, or manual entry). The CI record from the CMDB attaches to the incident automatically, giving the responder immediate access to:
- Full CI description and classification
- Hardware or software specifications
- Configuration attributes as of the last discovery cycle
- CI ownership and assigned support group
- Change history (recent changes to the CI)
- Service map position (via ViVID)
- Related CIs and dependencies
This context is available within the incident ticket — not in a separate CMDB interface. Responders see the full picture from the moment the ticket opens.
Can Incidents Be Automatically Created in Virima from External Monitoring Tools?
Yes. Virima 6.1.1 supports automated incident creation from external monitoring and event management systems.
When a monitoring tool detects a threshold breach or generates an alert, it sends the event to Virima via integration. Virima creates the incident record, identifies the affected CI from the alert data, links the CI to the incident, and routes the incident to the correct support group based on SLA rules — all without human intervention.
By the time a responder opens the incident, the CI is identified, the service map context is attached, and the SLA clock is running. The responder starts investigation immediately rather than spending the first 15-20 minutes reconstructing what is affected.
Virima also accepts incidents from email (auto-creates a record from inbound support emails) and from the self-service portal (user-submitted, with guided CI selection).
How Does ViVID Service Mapping Help During Incident Resolution?
ViVID is Virima’s automated service mapping capability. It maintains dependency-aware visual maps of all IT services, showing which CIs support which services and how services relate to each other.
During an active incident, ViVID provides three critical views:
Blast radius: Which services and CIs depend on the affected CI? A ViVID overlay on the incident shows every downstream dependency at risk — immediately, without manual investigation.
Dependency chain: Which upstream CIs does the affected CI depend on? If the root cause is a dependency failure (a database the application relies on, rather than the application itself), ViVID makes that visible in seconds.
Restoration sequence: For major incidents requiring staged recovery, the ViVID dependency chain shows which CIs to restore first. Responders follow the map rather than improvising a sequence based on incomplete knowledge.
ViVID service maps update automatically with each discovery cycle, so the service relationships responders see during an incident reflect the current environment — not a topology that was documented months ago and never updated.
Is Virima’s Incident Management ITIL v4 Compliant?
Yes. Virima 6.1.1 incident management aligns with ITIL v4 incident management practices across the full incident lifecycle: detection, logging, classification, diagnosis, resolution, and closure.
Key ITIL v4 elements present in Virima:
- Mandatory CI linkage on every incident record
- Impact and urgency matrix driving priority calculation
- SLA assignment based on incident priority
- Escalation workflows — functional and hierarchical, automated on SLA breach
- Major incident procedures — distinct P1/P2 routing, bridge coordination, and stakeholder notification
- Closure with documented resolution and CI state update
Virima also includes a workflow generator for custom incident routing. Teams build and activate routing rules — by CI class, incident category, priority, or any combination — without coding.
How Does Virima Help Reduce MTTR During Major Incidents?
MTTR reduction in Virima comes from eliminating the manual data reconstruction that extends every major incident bridge call.
In a standard major incident without CMDB context, responders spend significant time answering questions that should already be answered: What is the affected system? What depends on it? Who owns it? What changed recently? These questions consume 20-60 minutes on a typical major incident — before any actual diagnostic or remediation work begins.
With Virima CMDB context, those answers are present in the incident ticket from the first minute:
- Affected CI — identified automatically at incident creation
- Change history — last changes to the CI are visible without switching tools
- Service impact — ViVID shows the full blast radius immediately
- Ownership — CI owner and support group are in the CI record
- Dependencies — upstream and downstream CIs visible on the service map
Stakeholder communication is also faster. Virima’s service map context allows the incident manager to notify affected business units proactively — based on ViVID data — rather than reactively as downstream outages are reported one at a time.
The cumulative effect across major incidents is substantial MTTR reduction. Each major incident where the team saves 30-60 minutes of reconstruction time is a direct business impact reduction.
Can Virima’s Incident Data Feed into Problem Management?
Yes. Virima 6.1.1 supports the transition from incident management to problem management through CI-level incident history.
Every CI record in Virima tracks all incidents linked to it over time — how many, when they occurred, and how each was resolved. When a CI shows a pattern of recurring incidents, the data is immediately visible: this CI has had seven incidents in 90 days, five with the same resolution category.
Problem managers use this data to open formal problem records, referencing the contributing incidents and the affected CI. The CMDB change history for that CI — also accessible from the incident and problem records — helps identify the underlying cause: a configuration change, a software update, or a capacity constraint that keeps producing incidents.
This connection between incident history, CI data, and change history is what makes root cause analysis tractable in Virima, rather than requiring manual correlation across multiple systems.
What ITSM Integrations Does Virima Support for Incident Management?
Virima 6.1.1 integrates with the major ITSM platforms in use across enterprise IT:
- ServiceNow — bidirectional incident sync; CMDB data from Virima enriches ServiceNow incident records
- Jira Service Management — incident records and CI context passed to Jira workflows
- Ivanti — incident management integration for organizations running Ivanti ITSM
- HaloITSM — native integration with Halo’s incident and service desk workflows
- Hornbill — incident management data exchange with Hornbill Service Manager
- Xurrent (formerly 4me) — incident and CI data integration for Xurrent environments
- TeamDynamix — CMDB-backed incident enrichment for TeamDynamix ITSM users
For organizations already running one of these platforms, Virima does not replace the ITSM tool — it enriches it. Virima’s always-current CMDB and ViVID service maps provide the CI context that makes incidents in any of these tools more actionable.
For organizations without a dedicated ITSM platform, Virima 6.1.1 provides a complete, self-contained incident management capability built on ITIL v4 principles.
Conclusion
Virima 6.1.1 connects incident management to the CMDB automatically — not as a configuration project, but as a built-in capability. Every incident carries its CI, every CI carries its service map context, and every major incident gives responders an immediate, accurate picture of what is affected and what to do first.
The result is shorter incidents, faster root cause analysis, and an incident management CMDB integration documented trail from detection to CMDB incident linking itsm resolution that satisfies both operational and audit requirements.
