The task table — the foundation
Incident, Problem, Change, and several other tables all extend the base task table. Fields like number, short_description, assigned_to, assignment_group, state, priority, and comments_and_work_notes exist on task and are inherited. When you write a Business Rule on the task table, it fires for all task subclasses — be specific if you only want it to fire for incidents:
// Business Rule on task table — check sys_class_name to limit
if (current.sys_class_name == 'incident') {
// Only runs for incidents, not changes or problems
}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, close_code
Priority calculation: incident priority is derived from urgency and impact via the calc_priority Business Rule. Do not override priority directly unless intentionally bypassing this matrix.
// Detect state change to Resolved
if (current.state == '6' && previous.state != '6') {
gs.log('Incident ' + current.number + ' resolved', 'ITSM');
sendResolutionSurvey(current);
}
// Count open incidents for a caller
var ga = new GlideAggregate('incident');
ga.addEncodedQuery('active=true^caller_id=' + callerId);
ga.addAggregate('COUNT');
ga.query();
if (ga.next()) { return parseInt(ga.getAggregate('COUNT')); }Problem Management
Table: problem (extends task) | Key states: 100=Draft, 101=Assess, 102=Root Cause Analysis, 103=Fix in Progress, 104=Resolved, 105=Closed
Incidents relate to Problems via the problem field on the incident, or via the problem_task table. Multiple incidents can point to one problem. When the problem is resolved, all related incidents can be resolved automatically via Flow Designer.
Change Management
Table: change_request (extends task) | Types: Normal, Standard (pre-approved), Emergency
Key states: -5=Draft, -4=Assess, -3=Authorize, -2=Scheduled, -1=Implement, 0=Review, 3=Closed, 4=Cancelled
Change Tasks (change_task table) are the individual work items under a change. Always create change tasks for work breakdown — they provide granular progress tracking and can be assigned to different people.
// Get all changes in Implement state
var gr = new GlideRecord('change_request');
gr.addEncodedQuery('state=-1^active=true');
gr.query();
while (gr.next()) {
gs.log(gr.getValue('number') + ' — ' + gr.getValue('short_description'));
}Cross-module relationships
The three ITSM modules connect in a structured way. Incidents represent individual occurrences of issues. When the same issue occurs repeatedly, a Problem record is raised to find the root cause. When a fix is identified, a Change is raised to implement it. Understanding this flow is essential for building automation that spans modules.
Related guides: GlideRecord encoded queries · GlideAggregate · Flow Designer triggers for ITSM events · SLA management
The ITSM data model developers need to know
ITSM in ServiceNow is built on the task table hierarchy. The task table is the parent — incident, problem, change_request, sc_request, sc_req_item all extend it. Fields defined on task (number, state, assigned_to, assignment_group, short_description, work_notes, comments) are inherited by every task subtype. Understanding this hierarchy explains why a GlideRecord query on task with addEncodedQuery returns incidents, changes, and requests mixed together — all tasks live in the same database table with a discriminator column.
// Querying the task hierarchy correctly
// To get only incidents — query the incident table
var inc = new GlideRecord('incident');
inc.addEncodedQuery('active=true^priority=1');
inc.query();
// The task table query returns ALL task types (usually not what you want)
var task = new GlideRecord('task');
task.addEncodedQuery('sys_class_name=incident^active=true');
// Equivalent but slower — use the specific table insteadITSM Business Rules — the critical patterns
The most common ITSM scripting patterns involve reacting to state changes, priority changes, and assignment changes. The pattern structure is always the same: check whether the specific field changed using current vs previous, then take action:
// Business Rule: After save, async — fires when incident priority changes
if (current.priority.changes() && current.getValue('priority') == '1') {
// Priority escalated to P1 — page the on-call
gs.eventQueue('incident.priority.critical', current,
current.getValue('assigned_to'), current.getValue('assignment_group'));
}
// Check multiple conditions cleanly
var priorityChanged = current.priority.changes();
var assignmentChanged = current.assignment_group.changes();
var previouslyUnassigned = !current.previous_assignment_group;
if (assignmentChanged && previouslyUnassigned) {
// First assignment — trigger acknowledgement SLA start
}SLAs from a developer perspective
SLAs are stored in the task_sla table — each SLA attached to a task creates a task_sla record. The percentage field (0–100) shows how much of the SLA time has elapsed. The breached field (true/false) tells you whether the SLA has been missed. Build proactive alerting by querying task_sla with GlideAggregate for incidents approaching breach, or by adding a Flow Designer trigger on task_sla updates when percentage crosses 50% and 75%. See the SLA management guide for the full implementation pattern.
Related: Encoded queries · GlideAggregate · Flow Designer triggers · SLA management · Business Rules · Now Assist for ITSM
Change management scripting patterns
Change requests have a more complex state machine than incidents — they go through planning, approval, implementation, and review stages with conditional paths. The most common developer task in change management: build automation that prevents state transitions under certain conditions, and triggers specific actions at specific state transitions.
// Business Rule: Before save — prevent implementing without an approver
if (current.state.changesTo('implement') && current.getValue('state') == '-1') {
if (!current.getValue('u_implementation_lead')) {
current.setAbortAction(true);
gs.addErrorMessage('Implementation lead is required before moving to Implement.');
}
}
// Business Rule: After save async — notify CAB when change enters Review
if (current.state.changesTo('review') ||
(current.getValue('state') == 'review' && current.isNewRecord())) {
gs.eventQueue('change.entered.review', current,
current.getValue('assignment_group'), '');
}Related: Business Rules · Encoded queries · Flow Designer triggers · SLA management · Now Assist for ITSM
Problem management scripting
Problem management involves linking incidents to problems and tracking root cause analysis. The relationship between incidents and problems is stored in the problem_task_rel table. Common developer tasks: automatically propose a problem record when multiple P1 incidents share the same category and CI, and close linked incidents when a problem is resolved.
// Find incidents linked to a problem
var rel = new GlideRecord('problem_task_rel');
rel.addQuery('problem', problemSysId);
rel.query();
while (rel.next()) {
var taskId = rel.getValue('task');
var task = new GlideRecord('incident');
if (task.get(taskId)) {
gs.log('Linked incident: ' + task.getValue('number'));
}
}
// Check if incidents share same category/CI (for problem proposal)
var ga = new GlideAggregate('incident');
ga.addEncodedQuery('active=true^priority=1^category=network^opened_at>javascript:gs.daysAgo(1)');
ga.addAggregate('COUNT');
ga.groupBy('cmdb_ci');
ga.query();
while (ga.next()) {
if (parseInt(ga.getAggregate('COUNT')) >= 3) {
var ciId = ga.getValue('cmdb_ci');
// Three or more P1 network incidents on same CI in 24h — propose problem
proposeProblem(ciId, 'Network');
}
}This pattern — GlideAggregate to detect clustering, threshold check, automated problem creation — is a high-value automation for ITSM teams managing high incident volumes.
Knowledge management integration patterns
A common developer task is linking knowledge articles to incidents and surfacing relevant articles during incident creation. The kb_use table records when knowledge articles are viewed or linked from incidents. The standard pattern for suggesting relevant articles during incident creation: a GlideAjax call from a Client Script's onChange handler on the category or short_description field, querying the Knowledge Base for articles matching those criteria and populating a display field or informational message with the top results. This reduces time-to-resolution for agents who might not otherwise know relevant articles exist, and increases knowledge utilisation rates as a measurable ITSM KPI.
Developer contributions to ITSM process quality
The most impactful developer contributions to ITSM are often the invisible ones: automations that prevent common mistakes (required fields enforced by Business Rule before state transition), enrichment that reduces manual work (auto-populating category and subcategory based on CI type), and monitoring that surfaces problems proactively (SLA breach prediction alerts at 75% elapsed, assignment group performance dashboards). These contributions require ITSM domain knowledge — understanding why the process works the way it does — as much as scripting skill. Invest time in understanding your organisation's ITSM process design, not just the technical implementation. The developers who are most valued in ITSM implementations are those who can have a substantive conversation about process improvement and then implement the technical solution that supports it.
ITSM technical interview patterns
ITSM developer interviews at mid and senior levels test both scripting knowledge and ITSM domain understanding. Common question types: "How would you prevent an incident from moving to Resolved without a resolution note?" (Before Business Rule, setAbortAction if resolution_notes is empty when state changes to 6). "How would you automatically assign incidents to the correct group based on category?" (After Business Rule or Flow Designer trigger using a lookup table of category-to-group mappings). "How would you build a report showing SLA compliance by assignment group?" (GlideAggregate on task_sla with groupBy assignment_group, calculate met/total ratio). "How would you notify the previous assignee when an incident is reassigned?" (Before Business Rule checking assigned_to.changes(), storing previous value in a variable, After rule queuing notification event with previous assignee as target). These question types appear in technical interviews and are worth practicing on your PDI before your next interview.
ITSM development sits at the intersection of ServiceNow platform expertise and IT service management domain knowledge. Practitioners who develop both — who can design a Business Rule for an ITSM use case and also explain why the ITSM process it supports is designed that way — are the most effective and most valued members of ServiceNow implementation teams. Invest in both dimensions, not just the technical one.
The ServiceNow ITSM module documentation (docs.servicenow.com/csh?topicname=it-service-management) is the authoritative reference for ITSM table structures, field definitions, and API patterns. Bookmark it alongside the Developer Site (developer.servicenow.com/dev.do) — the combination of ITSM business context from the product documentation and scripting API reference from the developer site covers everything you need to implement ITSM customisations effectively.
ITSM development on ServiceNow is a long-term investment that compounds over time. Each Business Rule, Flow Designer flow, and Script Include you build correctly — maintainable, testable, well-documented — makes the next one easier and makes the system more reliable for the agents and users who depend on it. The highest-performing ITSM implementations are built by developers who care about the quality of the process they are supporting, not just the correctness of the code they are writing.