Incident Management
Table: incident (extends task)
Key states: 1=New, 2=In Progress, 3=On Hold, 6=Resolved, 7=Closed, 8=Cancelled
Key fields: number, caller_id, category, subcategory, priority, urgency, impact, assigned_to, assignment_group, state, resolved_at, resolution_notes
Priority calculation: Incident priority is calculated from impact and urgency using a priority matrix. The calc_priority Business Rule sets the priority field — be careful not to override this in your own rules unless intentionally.
// Check if incident is being resolved
if (current.state == 6 && previous.state != 6) {
// Incident just resolved
sendResolutionSurvey(current);
}Problem Management
Table: problem (extends task)
Key states: 100=Draft, 101=Assess, 102=Root Cause Analysis, 103=Fix in Progress, 104=Resolved, 105=Closed
Relationship to Incidents: Incidents can be related to Problems via the problem field on the incident, or via the problem_task relationship table. Multiple incidents can point to one problem.
Change Management
Table: change_request (extends task)
Types: Normal, Standard (pre-approved templates), Emergency
Key states: -5=Draft, -4=Assess, -3=Authorize, -2=Scheduled, -1=Implement, 0=Review, 3=Closed, 4=Cancelled
Change Tasks: change_task table — individual work items assigned to the change. Always create change tasks for the work breakdown, not free-form work notes.
The task table
Incident, Problem, Change, and several other tables all extend the base task table. Fields like number, short_description, assigned_to, assignment_group, state, and priority exist on task and are inherited. When you write a Business Rule on task, it fires for all task subclasses unless you filter by table.
// Business Rule on task table
// Check sys_class_name to limit to specific types
if (current.sys_class_name == 'incident') {
// Only runs for incidents
}