Incident Management in ServiceNow
What is an incident?
An incident is defined as one of the following:
- Unplanned interruption to an IT service
- Reduction in the quality of an IT service
- Failure of a configuration item (CI) that has not yet affected service
- An event that has not yet impacted the service to the customer
What is the goal of incident management?
- Restore a normal service operation as quickly as possible
- Classify incidents as you record them
- Ensure that the best possible levels of service quality and availability are maintained
Incident management State Model Flow
| State | When Used |
| New | Initial state of any new incident |
| In Progress | Set automatically upon assignment to an individual |
| On Hold | Investigation paused while awaiting information from the customer or an external vendor, or for provision of information, evidence, or a resolution from a related problem or change |
| Resolved | Service restored; awaiting customer confirmation or automatic closure |
| Closed | Final state of the incident, following automatic or manual closure |
| Canceled | Incident raised in error or identified as a duplicate of another incident record |
The Incident Management process has many states, and each is vitally important to the success of the process and the quality of service delivered. The different states can be represented in a diagram as follows:
Incident Management Process
- Incident Identification
- Incident logging
- Incident categorization
- Incident prioritization
- Incident routing and assignment
- Investigation and Diagnosis
- Incident resolution
- Incident resolution
Incident Identification
The first step in the life of an incident is incident identification. The service desk decides if the issue is truly an incident or if it is a request.
Incident logging
An incident can be logged through Email, phone calls, emails, Walk-in, created automatically or generated through another application.
In ServiceNow, Incident can be created through Service Portal, Incident Application or some events.
Service Portal:
End users can create and submit their own incidents through the Service Portal.
To create an incident, navigate to the Service Portal homepage, and then click Get Help. This directs you to the Service Catalog > Can We Help You? screen. Click Create Incident.
Incident Application:
Process users can create incidents manually from within the Incident application.
Other Applications:
Incidents can also be automatically created through events by integrating with different third party applications/tools.
Incident categorization
Incidents can be categorized and sub-categorized based on the area of IT or business that the incident causes a disruption.
Categorization provides the following benefits:
- Improves the clarity and granularity of report data.
- Assists in the future when you investigate similar incidents in the search for a resolution.
The value you select in the Category field determines the values you can select in the Subcategory field.
Incident prioritization
Incident prioritization drives the time frames associated with the handling of the incident and the targeted time to resolution.
Impact is a measure of the extent of the issue and of the potential damage caused by the incident before it can be resolved. This can be based on several factors including the number of affected users, potential financial losses, and criticality of affected services.
Urgency is a measure of the business criticality of an incident, when there is an effect upon business deadlines. The urgency reflects the time available to restore service before the impact is felt by the business.
Incident Routing and Assignment
Once the incident is categorized and prioritized, Incidents are automatically or manually routed to an Assignment Group, which is responsible for assigning an individual incident owner.
Once Assignment Group is filled, all group members receive an email notification. Then Assigned to can be filled by the group manager or any member of the assigned group.
The Assigned to values are limited to members of the selected group.
Assignment Group:
- Incidents are manually routed to an Assignment group by the incident creator or owner
- Incidents created via portal or email are likely to be routed to the service desk
Assigned to
- Select an Assigned to user from among the group members
- List of users is limited to members of the selected group
Investigation and Diagnosis
Once incident get assigned, the assigned user will start investigating to diagnose the issue. Based on the complexity of the incident,
Reassign or escalate if any additional support from various department, if required.
Create, assign and complete incident tasks, if required
While the incident is being processed, the technician needs to ensure the SLA isn’t breached. An SLA is the acceptable time within which an incident needs response (response SLA) or resolution (resolution SLA). The SLA is determined by the Priority value, and changes during the incident lifecycle only if the priority changes.
The SLA clock starts running as soon as an incident is saved. If the priority changes, the first SLA is canceled, and a new SLA begins with the same start time as the original; the SLA clock is not reset. The Response SLA clock stops as soon as the Assigned to field is completed and the state field is set to In Progress; meanwhile, the Resolve SLA clock continues to run.
Response SLA:
- Starts when incident is created.
- Completed when incident is assigned.
Resolution SLA
- Starts when incident is created.
- Paused if incident is set to on hold or resolved.
- Completed when incident is closed or Canceled.
Once the incident is diagnosed, service desk can apply a solution.
Incident resolution
An incident is considered resolved when the technician has come up with a temporary workaround or a permanent solution for the issue.
Once service is restored, ensure that you fully document the incident.
Communicate the resolution to the affected user and any associated stakeholders.
It also consists of activities like creating related problem or change records.
Incident Closure
An incident can be closed once the issue is resolved and the user acknowledges the resolution and is satisfied with it.
incidents will close automatically after seven days; some users may be given permission to manually close incidents before seven days.
Reference: https://docs.servicenow.com/