incident

What This Table Is

The incident table stores unplanned interruptions or reductions in quality of IT services. Every incident record represents a single service disruption that needs investigation, diagnosis, and resolution. This table drives the core ITSM incident management process from initial logging through closure and post-incident review.

The incident table belongs to the ITSM module and supports the complete incident lifecycle: logging, categorization, prioritization, assignment, investigation, resolution, and closure. It integrates with knowledge management, configuration management, and service catalog to provide context and accelerate resolution. The table feeds into availability reporting, trend analysis, and service improvement initiatives.

This table extends task, inheriting workflow state management, assignment capabilities, and SLA tracking. No tables extend incident directly, but it shares the task hierarchy with problem, change_request, and other ITSM processes. Incidents frequently reference problems through the problem_id field and link to configuration items via cmdb_ci.

Enterprise instances typically contain 100K-1M+ incident records with 1K-10K new incidents monthly. The table performs well for recent records but historical queries beyond 6-12 months require indexed filters. Active incident queries against state and assignment_group are heavily indexed and fast, while complex joins or unindexed field queries can timeout on large datasets.

When You'll Script Against This Table

You'll script against incidents primarily in Business Rules for workflow automation, Client Scripts for form validation and field population, and Script Includes for integration and reporting logic. Scheduled Jobs commonly query incidents for SLA monitoring, escalation processing, and metrics calculation. Flow Designer increasingly handles incident routing and notifications, but complex logic still requires server-side scripting.

The itil role provides full incident access, while incident_manager handles advanced operations. Assignment group membership controls read access to assigned incidents, and caller/watch list relationships enable self-service access. Scripts running as system bypass these restrictions but must respect business logic constraints.

Common scripting patterns:

• Automatic assignment based on category, location, or CMDB relationships
• Priority calculation from impact and urgency matrix with VIP overrides
• SLA attachment and breach calculation based on service and priority
• Related problem linking and known error matching for faster resolution
• Escalation triggers when incidents breach time thresholds or stall in queues
• Communication workflows for status updates to callers and stakeholders
• Integration with monitoring tools for automated incident creation and updates

Table Gotchas

• The caller_id field has reference qualifiers limiting selection to active users with specific roles, which can break API integrations if external systems reference inactive users
• Priority is often calculated automatically from impact and urgency, so setting priority directly may get overwritten by Business Rules on the next update

• The work_notes and comments fields clear after insert, so capture journal entries immediately in Business Rules before they're moved to the journal table
• SLA timers trigger on every incident update, not just state changes, causing performance issues when bulk updating large incident sets without proper SLA exemptions

Related Tables

The incident table extends task, inheriting core workflow fields like state, assigned_to, assignment_group, and SLA management capabilities. When querying task directly, include sys_class_name=incident to filter for incidents specifically, though querying incident directly is more efficient and provides incident-specific field access.

The sys_user table connects through caller_id and assigned_to for user context and contact information. The sys_user_group table links via assignment_group for routing and escalation logic. The cmdb_ci table connects through the cmdb_ci field to provide affected service context for impact assessment and automatic assignment rules.

Developers commonly join incidents with problem records through problem_id for root cause analysis and trend identification. The task_sla table stores SLA instance data for performance reporting and breach notifications. Integration scenarios frequently query sys_audit alongside incidents for change history and compliance audit trails.