Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

Incident Management state model

Log in to subscribe to topics and get notified when content changes.

Incident Management state model

Incident Management offers a flexible state model to move and track incidents through several states.

Note: While this new state model is available by default for new instances, it is not available on upgrade from versions prior to Helsinki. Refer to KB0564465 for information about implementing these state models if you upgrade from a previous version.

The following table provides a list of all the states that an incident can progress through.

Table 1. Incident states
State Description
New Incident is logged but not yet triaged.
In progress Incident is assigned and is being investigated.
On Hold The responsibility for the incident shifts temporarily to another entity to provide further information, evidence, or a resolution. When you select the On Hold option, the On hold reason choice list appears with the following options. This choice list is available only for new instances in Jakarta.
  • Awaiting Caller: If you select this option, the Additional comments field is mandatory.
    Note: If the caller updates the incident, the On hold reason field is cleared and the state of the incident is changed to In Progress. An email notification is sent to the user in the Assigned to field as well as to the users in the Watch list.
  • Awaiting Change
  • Awaiting Problem
  • Awaiting Vendor
Note: An incident can be placed in the On hold state one or more times prior to being closed.
Resolved A satisfactory fix is provided for the incident to ensure that it does not occur again.
Closed Incident is marked Closed after it has been in the Resolved state for a specific duration and it is confirmed that the incident is satisfactorily resolved.
Canceled Incident was triaged but found to be a duplicate incident, an unnecessary incident, or not an incident at all.
Figure 1. Incident management state model flow
Incident state flow diagram

If you are not satisfied with the resolution, you can request to reopen the incident from the resolution notification email or from the incident itself. The state of the incident is then changed from Resolved to In Progress. If the incident is already closed, you can open an incident with selected field values from the closed incident by replying to any email related to the closed incident. The values of the fields mentioned in the List of fields (comma-separated) to copy from the original incident when an incident is reopened by email property (com.snc.incident.clone_fields_on_reopen) are copied to the new incident. Add the text Please reopen to the subject line of the email.

If an incident is reopened by a user after it was resolved, the Last reopened by and the Last reopened at fields are automatically populated with the name of the person who reopened it and the date and time when the incident is reopened. During audit, this information helps you to generate various reports for reopened incidents.

In the Incident form, there is an existing field named Reopen count. For upgrade users, the existing incidents may already have some non-zero values in the Reopen count field while the values in the new fields, Last reopened by and the Last reopened at, are null. For incidents that are reopened after upgrade, the Last reopened by and the Last reopened at fields are populated.

If you do not have any roles in the system (ESS) and you change the incident state to Resolved, you receive a notification with a Reopen incident link.

If you do not have any roles in the system (ESS) and you are the caller, you can click Reopen incident on the incident form to reopen the incident.

Note: An ESS user is not able to resolve, reopen, or close a major incident even if the user is the caller.

Parent-Child state synchronization

The parent and the child incidents are synchronized such that the state of a child incident changes depending on the state of the parent incident.
Table 2. Parent-Child state synchronization
Parent State On Hold Reason (Parent) Child State On Hold Reason (Child)
In Progress NA In Progress NA
On Hold Awaiting Change/Awaiting Problem/Awaiting Vendor Same as parent Same as parent
On Hold Awaiting caller Not updated Not updated
Resolved NA Resolved.

Activity log on child incidents should be updated to Resolution notes copied from Parent Incident.

Closed NA Not closed.

Child incidents must always be closed by the caller or by the system based on the auto closure property.

Canceled NA NA NA
The parent-child synchronization functionality is only available for new customers starting with the Kingston release.
  • If a parent incident reopens, the child incident state should not change as the incident is already resolved.
  • When an incident has a child incident, the following actions take place:
    • If an ITIL user reopens the parent incident, then the parent incident as well as the child incident reopen. Both the parent and the child incident state is set to In Progress.
    • If an ESS user reopens the parent incident, the parent incident state is set to In Progress but the child incident is not reopened.

Incident-Incident task state synchronization

Incident tasks can be used by an incident owner to collaborate with and request work from other stakeholders.

The following property is responsible for different actions that take place on incident tasks based on the state of the incident:
  • The Close any open Incident Task when Incident is closed or canceled property (com.snc.incident.incident_task.closure) is responsible for the following action:
    • When an incident is closed, the state of any open incident task is set to Closed Incomplete.
    • When an incident is canceled, the state of any open incident task is set to Closed Skipped.
    Note: This property is set to true by default only for new (London) customers.