Incident Management ITIL V3 Module
Incident
An incident ticket or simply an “incident” keeps tracks of a technical issue within the IT:
-
System down
-
Network issue
-
Application failure
An incident can be linked to a problem (ticket). For instance, when the same incident is occuring often and you would like to investigate the root cause of the problem. An incident can be linked to a change (ticket), if it requires the implementation of a modification. For instance, when installing a patch.
Incident tickets are managed by people having the profile Support agent.
Incident Properties
Name | Type | Mandatory? |
---|---|---|
Organization | Foreign key to a(n) Organization | Yes |
Caller | Foreign key to a(n) Person | Yes |
Status | Possible values: Assigned, Closed, Escalated TTO, Escalated TTR, New, Pending, Resolved | Yes |
Origin | Possible values: mail, monitoring, phone, portal | No |
Title | Alphanumeric string | Yes |
Description | Multiline character string | Yes |
Service | Foreign key to a(n) Service | No |
Service subcategory | Foreign key to a(n) Service Subcategory | No |
Hot Flag | Possible values: No, Yes | No |
Hot reason | Alphanumeric string | No |
Pending reason | Multiline character string | No |
Impact | Possible values: A department, A service, A person | Yes |
Urgency | Possible values: critical, high, medium, low | Yes |
Priority | Possible values: critical, high, medium, low | Yes |
Team | Foreign key to a(n) Team | No |
Agent | Foreign key to a(n) Person | No |
Start date | Date and time (year-month-day hh:mm:ss) | No |
Last update | Date and time (year-month-day hh:mm:ss) | No |
Assignment date | Date and time (year-month-day hh:mm:ss) | No |
TTO Deadline | Core:AttributeStopWatch+ (100_deadline) | No |
TTR Deadline | Core:AttributeStopWatch+ (100_deadline) | No |
Last pending date | Date and time (year-month-day hh:mm:ss) | No |
Resolution date | Date and time (year-month-day hh:mm:ss) | No |
Close date | Date and time (year-month-day hh:mm:ss) | No |
Parent incident | Foreign key to a(n) Incident | No |
parent problem id | Foreign key to a(n) Problem | No |
Parent change | Foreign key to a(n) Change | No |
Resolution code | Possible values: assistance, bug fixed, hardware repair, other, software patch, system update, training | No |
Solution | Multiline character string | No |
Resolution delay | Core:AttributeDuration+ | No |
User satisfaction | Possible values: Very satisfied, Fairly statisfied, Rather Dissatified, Very Dissatisfied | No |
User comment | Multiline character string | No |
SLA tto passed | Core:AttributeStopWatch+ (100_passed) | No |
SLA tto over | Core:AttributeStopWatch+ (100_overrun) | No |
SLA ttr passed | Core:AttributeStopWatch+ (100_passed) | No |
SLA ttr over | Core:AttributeStopWatch+ (100_overrun) | No |
Tabs
Tab | Description |
---|---|
CIs | All the configuration items impacted for this ticket |
Contacts | All the contacts linked to this ticket |
Child incidents | All the child incidents related to this incident |
related request list | |
Work orders | All the work orders for this ticket |
Creating a Incident
Managing Public & Private Log
Please refer to User requests management
Managing impacted CIs and Contacts
Please refer to User requests management
Dependencies with service catalog
Please refer to User requests management
Assigning a user request to a team and agent
Please refer to User requests management
Automated priority computation
Please refer to User requests management
Deadline computation
Please refer to User requests management
Grouping related incidents
It is sometimes useful to regroup incident tickets under an incident which is the root cause of the issue. For instance when a network device is down, you may have several servers reported as “not responding”.
To group tickets, use the field parent incident.
When an incident is parent of another ticket, each time its private and public logs are modified, iTop will automatically update the logs of the child tickets. When the parent incident get resolved, iTop will automatically resolve the child incidents.
Incident Life Cycle
Incident objects have the following life cycle:
Depending on the status of the object, the contraints on the properties vary as shown on the table below:
New | Assigned | Escalated TTO | Resolved | Pending | Escalated TTR | Closed | |
---|---|---|---|---|---|---|---|
Organization | M | M | M | R/O | M | M | R/O |
Caller | M | M | R/O | R/O | |||
Status | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
Origin | R/O | R/O | |||||
Title | R/O | R/O | |||||
Description | R/O | R/O | |||||
Service | M | R/O | |||||
Service subcategory | R/O | ||||||
Hot Flag | H | H | R/O | R/O | |||
Hot reason | H | H | R/O | R/O | |||
Pending reason | H | H | H | R/O | M | H | R/O |
Impact | R/O | R/O | |||||
Urgency | R/O | R/O | |||||
Priority | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
Team | H | M | R/O | M | M | R/O | |
Agent | H | M | H | R/O | M | M | R/O |
Start date | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
Last update | R/O | R/O | R/O | R/O | R/O | R/O | R/O |
Assignment date | H | R/O | H | R/O | R/O | R/O | R/O |
TTO Deadline | R/O | H | R/O | H | H | H | H |
TTR Deadline | H | R/O | H | H | H | R/O | H |
Last pending date | H | H | H | H | R/O | H | H |
Resolution date | H | H | H | R/O | H | H | R/O |
Close date | H | H | H | H | H | H | R/O |
Parent incident | R/O | R/O | |||||
parent problem id | R/O | R/O | |||||
Parent change | R/O | R/O | |||||
Resolution code | H | H | H | M | H | H | R/O |
Solution | H | H | H | M | H | H | R/O |
Resolution delay | H | H | H | R/O | H | H | R/O |
User satisfaction | H | H | H | H | H | H | |
User comment | H | H | H | H | H | H | |
SLA tto passed | H | R/O | H | R/O | H | R/O | R/O |
SLA tto over | H | R/O | H | R/O | H | R/O | R/O |
SLA ttr passed | H | H | H | R/O | H | H | R/O |
SLA ttr over | H | H | H | R/O | H | H | R/O |
-
H: hidden
-
R/O: read-only
-
M: mandatory