Incident Management PDF

PDF generated on March 26, 2018
ServiceNow Documentation
This PDF was created from content on docs.servicenow.com. The web site is updated frequently.
For the most current ServiceNow product documentation, go to docs.servicenow.com.
Some examples and graphics depicted herein are provided for illustration only. No real
association or connection to ServiceNow products or services is intended or should be inferred.
You can find the most up-to-date technical documentation on the ServiceNow web site at:
http://docs.servicenow.com
The ServiceNow site also provides the latest product updates.
If you have comments about this documentation, submit your feedback to:
docfeedback@servicenow.com
Company Headquarters
2225 Lawson Lane
Santa Clara, CA 95054
United States
(408)501-8550
© 2018 ServiceNow. All rights reserved.

Terms of Use Privacy Statement
ServiceNow |
Contents
Incident Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Incident Management process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Incident Management state model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Incident priority and data lookup rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Improvements for the Incident Management process. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Major incident management process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Incident configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Incident management properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Incident categories and subcategories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Incident templates and record producers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Define an assignment rule for incidents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Incident promotion UI actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Specify the field a KB article is copied to. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Show flagged VIPs in the incident list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Configure incidents to close automatically. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Create a UI action to close multiple incidents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
View incident notifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Create trigger rules for major incidents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Activate Incident Management - Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Installed with Incident Management - Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Activate Incident Management Best Practice – Kingston. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Installed with Incident Management Best Practice – Kingston. . . . . . . . . . . . . . . . . . . . 39
Activate Incident Management - Major Incident Management. . . . . . . . . . . . . . . . . . . . . . . . 41
Installed with Incident Management - Major Incident Management. . . . . . . . . . . . . . . 42
Create an incident. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Use a template in the Incident form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Log an incident through Self-Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Copy an incident or create a child incident. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Work on incidents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Assign and update incidents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Use a dependency view to locate affected CIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Promote an incident. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Create a knowledge article from an incident. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Major incident management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Major incident workbench. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Incident resolution and closure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Best Practice - Incident Resolution Workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Close multiple incidents from a list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
March 26, 2018 ©2018 ServiceNow. All rights reserved. 3

ServiceNow |
Close multiple incidents from the UI action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Incident monitoring and tracking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Out-of-the-box Incident Management Performance Analytics Solutions. . . . . . . . . . . 71
Out-of-the-box Incident SLA Management Performance Analytics Solutions . . . . . 72
Major incident overview (dashboard). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Incident ticketing integrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

ServiceNow | Incident Management
Incident Management
Last updated: November 16, 2017
The goal of Incident Management is to restore normal service operation as quickly as

possible, while minimizing impact to business operations and ensuring quality is maintained.
ServiceNow Incident Management supports the incident management process in the

following ways.
• Log incidents in the instance or by sending email.

• Classify incidents by impact and urgency to prioritize work.
• Assign to appropriate groups for quick resolution.
• Escalate as necessary for further investigation.
• Resolve the incident and notify the user who logged it.
• Use reports to monitor, track, and analyze service levels and improvement.
Any user can record an incident and track it through the entire incident life cycle until
service has been restored and the issue has been resolved.
Explore Set up Administer
• Incident Management release • Create an incident template • Specify the field a KB article is
notes • Create a record producer copied to
• Incident Management process • Configure incident categories • Show flagged VIPs in the
• Incident Management state or subcategories incident list
model • Define an assignment rule for • Performance Analytics for
• Incident Management service incidents Incident Management
improvements • Incident promotion UI actions
• Upgrade to Kingston
Use Develop Integrate
• Create an incident • Developer training • Incident ticketing integrations

• Major incident management • Developer documentation
• Copy an incident or create
child incident
• Promote an incident
• Assign and update incidents
• Log an incident through Self-
Service (end users)
Troubleshoot and get help
• Ask or answer questions in the

Incident Management
community
• Search the HI knowledge base
for known error articles
• Contact ServiceNow Support

Incident Management process

ServiceNow Incident Management supports the incident management process with the
ability to log incidents, classify by impact and urgency, assign to appropriate groups,
escalate, resolve, and report.
Any user can record an incident and track it until service is restored and the issue is
resolved. Each incident is generated through various methods as a task record that contains
pertinent information. Incidents can be assigned to appropriate service desk members, who
document the investigation and resolve the task. After the incident is resolved, it is closed.
For information about auto-closing incidents, see Change the duration of the incident auto-
close function.
Any user can log an incident within the system using the following methods.
Introduction to incident management; creating, working on,
resolving, closing, and reopening an incident; creating a
knowledge base article from an incident; escalating an incident;
creating a problem or change from an incident.
Logging an incident
Location Process
Service desk call or walk-in Service desk (ITIL) agents can log incidents from
the Create New module in the Incident
application, or by selecting New from the Incident
list.
Service catalog ESS users can use the Create a New Incident
record producer in the service catalog.
This record producer sets the Contact Type field
of the resulting incident to Self-Service.

Location Process
Email An email addressed to the instance mailbox can
create an incident according to inbound email
actions.
Note: If Security Incident Response plugin is activated, you can click the Create
Security Incident button on the New Incident form to create a security
incident from the currently displayed incident.
ESS users can view the incidents they have opened. By default, the Watch list, State, and
Urgency fields are available on the ESS view of the Incident form. ESS users can update the
Watch list and Short Description fields, and enter Additional comments. The administrator
can configure other fields to be editable.
Users who do not have the itil role can view incidents if they have opened the incident, are
the caller, or are included in the watchlist. The incident query business rule controls this
function.
The incident alert management application allows you to manage communications around
high-priority incidents. For more information, see Incident Alert Management.
Generating incidents
In addition to having users logging incidents, they can be automatically generated from pre-
established conditions. Business rules use JavaScript to generate an incident after a certain
series of conditions has been met. For more information, see Business rules .
It is also possible to generate incidents from outside the platform with SOAP messaging. For
more information, see SOAP messaging .
• Incident Management state model
Incident Management offers a flexible state model to move and track incidents through
several states.
• Incident priority and data lookup rules
ITIL uses three metrics for determining the order in which incidents are processed.
• Improvements for the Incident Management process
The service desk can improve the incident management process using information
gathered within the platform.
• Major incident management process
Major incident management process involves proposing an incident as a major incident

candidate, accepting the candidate as a major incident, working with the major incident
management group and different stakeholders to resolve an issue and to communicate
between different group members.
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.
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 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.

Incident management state model flow
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 reopen it by
replying to any email related to that incident. Add the text Please reopen to the subject line.
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.
The parent and the child incident is synchronized such that the state of a child incident
changes depending on the state of the parent incident.
Parent-Child state synchronization

Parent State On Hold Reason Child State On Hold Reason (Child)
(Parent)
On Hold Awaiting Change/ Same as parent Same as parent
Awaiting Problem/
Awaiting Vendor
On Hold Awaiting caller Not updated Not updated

Parent State On Hold Reason Child State On Hold Reason (Child)

(Parent)
Resolved NA Resolved. NA
Activity log on child
incidents should be
updated to Resolution
notes copied from
Parent Incident.
Closed NA Not closed. NA

Child incidents must
always be closed by the
caller or by the system
based on the auto
closure property.
Canceled NA NA NA
Note: If parent incident reopens then child incident state should not change as the
incident is already resolved. The parent-child synchronization functionality is
only available for new customers.
Related Concepts
Related Reference
Incident priority and data lookup rules

ITIL uses three metrics for determining the order in which incidents are processed.
Supported metrics
ITIL incident metric order

Field Definition
Impact The effect that the task has on business.
Urgency The extent to which the task resolution can be
delayed.
Priority How quickly the service desk should address the
task.
Priority calculation
Priority is calculated according to the following data lookup rules:

Data lookup rules

Impact Urgency Priority
1 - High 1 - High 1 - Critical
1 - High 2 - Medium 2 - High
1 - High 3 - Low 3 - Moderate
2 - Medium 1 - High 2 - High
2 - Medium 2 - Medium 3 - Moderate
2 - Medium 3 - Low 4 - Low
3 - Low 1 - High 3 - Moderate
3 - Low 2 - Medium 4 - Low
3 - Low 3 - Low 5 - Planning
By default, the Priority field is read-only and must be set by selecting the Impact and
Urgency values. To change how priority is calculated, administrators can either alter the
priority lookup rules or disable the Priority is managed by Data Lookup - set as read-only UI
policy and create their own business logic.
In the Priority [dl_u_priority] table, you can modify data lookup rules for task priority.
Work notes
When you initially create and save an incident, the Work notes field is not mandatory. If you
change the priority of the incident by selecting different Impact or Urgency values on an
incident form that has already been saved, the Work notes field becomes mandatory.
Note: This feature is available only for new instances, starting with the Jakarta
release.
Related Concepts
Related Reference
Improvements for the Incident Management process

The service desk can improve the incident management process using information gathered
within the platform.
In addition to the data stored within the incident record, the administrator can enable
auditing , which allows for an accurate review of the history of the issue.
The following plugins allow for further investigation and analysis of incidents:

Incident information plugins

Plugin Definition
Metric Definition Define the metrics to monitor within the system.
With these metrics, and the information within
the database, it is possible to generate reports
that can be added to homepages or
automatically generated and distributed.
Database views Join tables for reporting purposes. For example, a
database view can join the Incident table to the
Metric Definition and Metric Instance tables for
reporting and analysis.
Vendor ticketing Add vendor data to incidents and integrate with
vendor performance .
Using this information, it is possible to refine automatic rules such as the assignment rules,
service level agreements, or inactivity monitors to better suit the unique environment of the
service desk.
Unnecessary incidents can be avoided by encouraging users to consult the knowledge base
before creating an incident. The related search results function in the Incident form assists
with this strategy.
Related Concepts
Related Reference
Major incident management process

Major incident management process involves proposing an incident as a major incident

candidate, accepting the candidate as a major incident, working with the major incident
management group and different stakeholders to resolve an issue and to communicate
between different group members.
If a critical business service is impacted or if there is a service outage that affects large
number of users, you can create a major incident. To create a major incident, you first
propose that an incident becomes a major incident candidate. You can also create a new
major incident candidate by clicking Create Major Incident Candidate from the left
navigation pane. The major incident manager then analyses the candidate and decides
whether a major incident is at all required. The Create major incident from candidate
property (sn_major_inc_mgmt.com.snc.incident .min.major_incident_creation) provides
option to create a new major incident or to promote a major incident candidate to a major
incident.

Note: The base system major incident trigger rules are disabled by default. You
need to activate the trigger rules that define conditions under which an
incident is automatically considered as a major incident candidate.
When you create a new major incident from a candidate, a new incident is created and
becomes the major incident. The candidate is added as the child of the major incident. The
major incident is automatically assigned to the Major Incident Management group. System
automatically assigns the newly created parent major incident to a user when the On-Call
Scheduling plugin (com.snc.on_call_rotation) is activated, a rota is defined for the major
incident management group, and a user is available for the on-call rota. If no on-call rota
exists, the major incident manager decides the user for the Assigned to field.
When a major incident candidate is promoted as a major incident, the incident itself is
considered as a major incident. There is no new incident that is created. The value in the
existing Assignment group or the Assigned to field does not change to the major incident
management group or any user. The major incident manager needs to reassign the value of
the fields as appropriate.
One of the crucial things in responding to a major incident is to involve right resources,
communicate updates to the required users, initiate conference calls, and escalate an
incident when required. In the Incident Alert (incident_alert) table, a new column Type is
added that has Technical Communication and Business Communication as its value. To cater
to the requirements, when a major incident is created, two incident alerts are generated
automatically. These alerts appear in the Incident Alerts related list — Technical and Business
Communication. Each of these incident alerts have incident alert tasks created automatically
for managing collaboration and communication activities such as initial, update, and
resolution notifications.
You can configure the automatic creation of Incident Alerts and Incident Alert Tasks using
the Flow Designer .
For email communication, there are pre-composed email client templates for business as
well as technical communication that is created for the Incident Alert Task
[incident_alert_task] table.
Related Tasks
• Create trigger rules for major incidents
Related Concepts
• Major incident management
• Installed with Incident Management - Major Incident Management
• Major incident workbench
• Major incident overview (dashboard)
Related Reference

Incident configuration
You can configure the incident form and other incident features, such as incident categories
and UI behavior.
The Incident form is configured in the base system to follow recommended ITIL practices.
The administrator can configure the incident form and use the form designer to customize it.
You can copy or create child incident to reduce the effort of configuring the functionality of
an open incident. The following list describes the options to configure the Incident form
from the form context menu Configure option.
Form configuration and design

Menu option Description
Form design Administrators or users with the
personalize_form role can use the form design
feature to quickly create new or change existing
form views. Form design is an alternative to
configuring forms that combines several
configuration options into one tool.
Form layout Administrators or users with the
personalize_form role can configure a form to
show or hide fields from a view. New fields can be
created on the table associated with the form.
Related lists Related lists display records in another table that
have a relationship with the current record.
Administrators or users with the
personalize_form role can configure related lists
to appear on the form.
• Incident management properties
Incident management properties are used to control features such as copying and
creating child incidents. The major incident properties control the promotion of major
incident candidates to major incidents.
• Incident categories and subcategories
Assigning incident tickets to categories and subcategories allows for easy classification of
incidents. Categories and subcategories are also used with reporting.
• Incident templates and record producers
Templates simplify the process of submitting new records by populating fields

automatically. A record producer is a specific type of catalog item that allows end users
to create task-based records, such as incident records, from the service catalog.
• Define an assignment rule for incidents
To ensure that incidents are brought to the attention of the appropriate IT agents, you can
define assignment rules to automate the process.
• Incident promotion UI actions

UI actions add links in the Incident form context menu to promote incidents to problems,
changes, or requests. Administrators can customize incident promotion behavior.
• Specify the field a KB article is copied to
When a user searches for a knowledge base article from an incident, problem, or change
request, the displayed article includes an Attach button at the top right. The task
displayed on the button matches the form where the search was initiated.
• Show flagged VIPs in the incident list
Organizations commonly designate VIP status in the user record for some of their VIP
users. The administrator can add the VIP field to the user record form to designate those
users. If the Incident list view is configured to display Caller, VIPs are visually flagged.
• Configure incidents to close automatically
You can configure a system property to automatically close tickets that have been in
Resolved state for a specified number of days. You can also change the user who is
assigned by default in the Updated by field when an incident is automatically closed.
• Create a UI action to close multiple incidents
You can create a UI action to close multiple incidents from the Actions choice list in the
list view. It adds the same close note to all the incidents being closed, and does not
require the list_updater role. Implementing this process also requires a business rule for
the UI action to reference and a custom form view.
• View incident notifications
You can view the incident notifications that are sent during specific events in an incident
life cycle. These notifications are sent to various recipients including ESS and ITIL users.
Create trigger rules to define conditions under which a trigger action is executed. You can
create major incident trigger rules to define conditions under which an incident is
automatically considered as a major incident candidate.
Incident management properties

Incident management properties are used to control features such as copying and creating
child incidents. The major incident properties control the promotion of major incident
candidates to major incidents.
These properties are available at Incident > Administration > Incident Properties.
Properties for incident management

Property Description
Number of days (integer) after which Resolved Sets the duration of the incident auto-close
incidents are automatically closed. Zero (0) function.
disables this feature
glide.ui.autoclose.time

List of fields (comma-separated) to copy from Enter the name of the fields that you want to be
the original incident when an incident is reopened copied from the original incident to the new
by email incident when you reopen an incident through
com.snc.incident.clone_fields_on_reopen email.
Note: When an incident is reopened, a

new incident is created.
Enable copy incident feature Select the check box to get the Copy Incident
com.snc.incident.copy.enable option in the context menu.
Enable create child incident feature Select the check box to get the Create Incident
com.snc.incident.create.child.enable option in the context menu.
Copy attachments from originating incident Select the check box to copy attachments from
com.snc.incident.copy.attach original incidents when an incident is copied for
created.
List of attributes (comma-separated) that will be Enter the name of the attributes that you want to
copied from the originating incident be copied from the original incident to the new
com.snc.incident.copy.attributes incident when you copy or create an incident.
Related lists (comma-separated) that will be Enter the name of the related lists that you want
copied from the originating incident to be copied from the original incident to the new
com.snc.incident.copy.related_lists incident when you copy or create an incident.
List of attributes (comma-separated) from Enter the name of the attributes from Affected
Affected CIs (task_ci) related list that will be CIs related list that you want to be copied from
copied from the originating incident the original incident to the new incident when
com.snc.incident.copy.rl.task_ci.attributes you copy or create an incident.
List of attributes (comma-separated) from Enter the name of the attributes from Impacted
Impacted Services (task_cmdb_ci_service) Services related list that you want to be copied
related list that will be copied from the from the original incident to the new incident
originating incident when you copy or create an incident.
com.snc.incident.copy.rl.task_cmdb_ci_services.attributes
Show "Create Incident" link after a Knowledge Select the check box to get the Create Incident
article is rated not helpful link and provide your feedback about a
glide.knowman.create_incident_link.display knowledge article.
URL used for the "Create Incident" link after Enter the URL of the knowledge article.
rating a Knowledge article not helpful
glide.knowman.create_incident_link
List of fields (comma-separated) that appear in Enter the names of the fields that are visible in
the activity formatter for Incident the activity formatter. If the activities are
glide.ui.incident_activity.fields personalized, this property updates automatically.
Additional comments icon used in Task Activity Enter the path of the icon that is used for
formatter additional comments.
glide.ui.incident_activity.image.comments
Work notes icon used in Task Activity formatter Enter the path of the icon that is used for work
notes.

glide.ui.incident_activity.image.work_notes
Incident additional comments style Enter the html syntax of comment style for
glide.ui.incident_activity.style.comments incident additional comments.
Incident work notes style Enter the html syntax of comment style for
glide.ui.incident_activity.style.work_notes incident additional comments.
Major incident management

These properties are available at Incident > Administration > Major Incident Properties.
Properties for major incident management

Create major incident from candidate Provides option to create a new major incident or
sn_major_inc_mgmt.com.snc.incident .min.major_incident_creation
to promote a major incident candidate to a major
incident.
Compose Email on Major Incident Overview Provides comma-separated list of Incident Alert
sn_major_inc_mgmt.com.snc.incident.mim.compose_email_on_iatasks
Task types that can have Compose Email option
on Major Incident Workbench.
Incident categories and subcategories

Assigning incident tickets to categories and subcategories allows for easy classification of
incidents. Categories and subcategories are also used with reporting.
The platform can also use incident category or subcategory to automatically assign the
incident to a specific fulfillment group. For example, Network tickets can be assigned
automatically to the Network group based on the category.
Using categories and subcategories also improves the clarity and granularity of report data.
For example, appropriate incident categories allow you to track how many network-related
versus telephone-related incidents you have from week to week.
The following categories and associated subcategories are in the base system. An
administrator can add additional categories and subcategories, and use them in assignment
rules and notifications.
Incident categories
Category Subcategory
Inquiry / Help Anti-Virus
Email
Internal Application
Software Email

Category Subcategory
Operating System
Hardware CPU
Disk
Keyboard
Memory
Monitor
Mouse
Network DHCP
DNS
IP Address
VPN
Wireless
Database DB2
MS SQL Server
Oracle
Configure incident categories or subcategories

You can add to or remove choices from the lists of incident categories and subcategories.
Before you begin
Role required: admin
About this task
If the Subcategory field does not appear, the administrator can configure the incident form
to display it.
Procedure
1. Navigate to Incident > Create New.

2. Perform one of the following steps.
Option Description
Edit Category choices Right-click the Category field and select
Configure Choices.
Edit Subcategory choices Select the Category to update its subcategory

choices. Right-click the Subcategory field and
select Configure Choices.

3. Perform any of the following actions.
Option Description
Add new category Click New, specify a Label and Value, and then
click Submit.
Add existing category Highlight the required category and click Add.
Remove existing category Highlight the category to be removed and click

Remove.
4. Click Save.
Related Tasks
• Change the None display value for a choice list
Related Topics
• Change the None display value for a choice list
Incident templates and record producers

Templates simplify the process of submitting new records by populating fields automatically.
A record producer is a specific type of catalog item that allows end users to create task-
based records, such as incident records, from the service catalog.
Incident templates can be used to quickly enter incidents for similar issues or questions.
Users with the itil role can create personal templates for incidents they log frequently. An
administrator or user with the template_editor_global role can create templates that are
available to everyone. An administrator can enable the global option for any personal
template that a user has entered, so that all agents have access to it.
ESS users typically log incidents using a record producer in the service catalog. A template
can be used to create an incident record producer. The template populates fields in the
Incident form that the user submitting the incident does not see.
For example, an incident record producer can be created to request account access to a
network server. The user who submits the incident enters variable values, such as the server
name, level of access needed, and due date. The incident template assigned to the record
producer populates the incident Category, Subcategory, and Assignment Group. These
fields and values applied from the template do not appear in the record producer form.
• Create an incident template
Create an example template to use in the Incident form.

• Add a module that uses a template
You can add a module that allows an end user to log an incident with prefilled field values
from an existing template.
• Create a record producer to log incidents

Record producers allow the end user to log incidents directly from the Service Catalog.
The first step in using the service catalog to log incidents is to create an incident record
producer.
• Create a record producer using a template
If a predefined incident template exists, it can be used with the record producer to fill in
standard information for the incident.
Related Tasks
• Create a record producer
Related Topics
• Create a template using the Template form
Create an incident template

Create an example template to use in the Incident form.
Before you begin
About this task
In this example, create a template to log an incident when a user is denied access to the
Bond Trading application.
Procedure
1. Navigate to System Definition > Templates.

2. Complete the steps in Create a template using the Template form.
3. Enter the following information.
• Name: Bond Trading Access Denied
• Table: Incident
• Global: Select the check box. The Global option allows any user to use the template,
not just the template creator.
• Short Description: Bond Trading Access Denied
• Template: Add the following values to define the fields that are filled in when the
template is used.
[Category] [Inquiry / Help]
[Configuration Item] [Bond Trading]
[Description] [The user was denied access to the Bond Trading application]
[Impact] [2 - Medium]
[Urgency] [3 - Low]

Incident Template
Related Tasks
Add a module that uses a template

You can add a module that allows an end user to log an incident with prefilled field values
from an existing template.
Before you begin
About this task
The following example demonstrates how to place the Bond Trade Access Denied template
into a module in the Self-Service application.
Procedure
1. Point to Self-Service and click the edit icon (pencil).

2. Click New in the Modules related list.

• Title: Bond Trading Access Denied

• Order: 473. This order places the new module after Requested Items in the Self-
Service application.
• Hint: Log an incident about the Bond Trade application.
Link Type section:
• Link Type: New Record

• Table: Incident
• Arguments: incident.do?sys_id=-1&sysparm_template=Bond Trading Access Denied.
This path deploys the template in the new incident record.
Incident template
4. Click Submit.
The new module appears in the Self-Service application.
Related Tasks
Create a record producer to log incidents

Record producers allow the end user to log incidents directly from the Service Catalog. The
first step in using the service catalog to log incidents is to create an incident record
producer.
Before you begin

Role required: catalog_admin or admin
About this task
Record producers appear in the service catalog as catalog items. Instead of creating a
service request, they create a record on any table in the system, populating the record as
defined in the record producer.
Incident record producers provide users with one interface from which to submit requests to
IT. For example, the default Can We Help You? category features record producers such as
Create Incident to enable users to log incidents from the catalog.
The following example demonstrates how to create a record producer to request a wireless
router reset.
Procedure
1. Navigate to Service Catalog > Catalog Definitions > Record Producers.

2. Click New and follow the steps in Create a record producer.
Field Entry
Name Request to Reset Router.
Table name Incident [incident].
What it contains
Short description Reset wireless router request
Description Please reset the building's router.
Accessibility
Catalogs Service Catalog
Category Can We Help You?
Record producer form

4. Open the form context menu and click Save.

Several related lists appear at the end of the form, including Variables and Variable Sets.
5. In the Variables related list, click New.
6. Enter or select the following values.
Field Entry
Type Reference
Question Which router needs to be reset?
Name Router
Type Specifications
Reference IP Router [cmdb_ci_ip_router]
Router reset variable
7. Click Submit.
8. (Optional) To view the new record producer as a user sees it, click Try It in the form
header.

New catalog item preview
The new catalog item appears in the Service Catalog for any user to select.
Service Catalog category with new item
Related Tasks
Create a record producer using a template

If a predefined incident template exists, it can be used with the record producer to fill in
standard information for the incident.

Before you begin
Role required: catalog_admin or admin
Procedure
1. Navigate to Service Catalog > Catalog Definitions > Record Producers.

2. Click New and follow the steps in Create a record producer .
3. On the Generated Record Data tab or section, select the incident template to populate
fields when the record producer is submitted.
4. Open the form context menu and click Save.
Several related lists appear.
5. Complete any of the following tasks.
• Enter variables.
• Associate with a catalog and category.
• Add user criteria.
6. Click Submit.
Related Tasks
Define an assignment rule for incidents

To ensure that incidents are brought to the attention of the appropriate IT agents, you can
define assignment rules to automate the process.
Before you begin
Role required: assignment_rule_admin or admin
About this task
This example adds an assignment rule to assign database issues in New York to the NY DB
assignment group.
Procedure
1. Navigate to System Policy > Assignment and complete the steps in Create an
assignment rule
2. Enter the following information for the example.
Field Entry
Name New York Database Issues
Table Incident [incident]
Execution Order 50

Field Entry
If this field does not appear, the administrator
can configure the form.
Group NY DB
Note: The sys_user_group read ACL

calls the SNCRoleUtil function.
The function checks whether
the group being selected
contains either the admin or
security_admin role. The
function allows the user to view
the group only if the user has
the same role. As a result, an itil
user cannot assign an incident
to a group that has the admin
role or security_admin role, or
whose parent has the role.
Conditions [Location] [is] [New York] and [Category] [is]

[Database].
3. Click Submit.
4. Test the assignment rule by completing the following steps.
a. Navigate to Incidents > Create New.
b. Enter New York in the Location field and Database in the Category field.
c. Complete other mandatory fields and click Submit.
d. Reopen the incident and see that the NY DB assignment group was added.
Incident promotion UI actions

UI actions add links in the Incident form context menu to promote incidents to problems,
changes, or requests. Administrators can customize incident promotion behavior.
Incident promotion UI actions

The image depicts the UI actions that are used to promote incidents. Administrators and
users with the ui_action_admin role can edit them to customize the behavior of the menu
item.
Create Problem UI action

The Create Problem script copies these fields from the Incident form:
• short_description
• cmdb_ci
• priority
• company
The syntax for copying a field from the Incident form to the Problem form is:
prob.<fieldname> = current.<fieldname>
Create Request UI action

The Create Request script redirects the user to the service catalog. The service desk agent
locates the catalog item and orders it. The Caller is copied to the Requested for user in the
request.
release.
Create <type of> Change UI action

The Create Normal Change and Create Emergency Change scripts copy these fields from
the Incident form:
• short_description
• description
• cmdb_ci
• priority
• company
The syntax for copying a field from the Incident form to the Change form is:
change.<fieldname> = current.<fieldname>
Other UI actions for incident promotion

If there is another process that incidents may be promoted to, such as a facilities request,
create a UI action. Model it after the Create Normal Change and Create Problem UI actions
to promote the incident to that table.
Related Tasks
Specify the field a KB article is copied to


When a user searches for a knowledge base article from an incident, problem, or change
request, the displayed article includes an Attach button at the top right. The task displayed
on the button matches the form where the search was initiated.
Before you begin
About this task
When you click the Attach button, the article number and contents are copied into the
Comments or Description field of the incident, problem, or change record by default.
Administrators can set a property to customize where the copied article is placed.
The copy behavior is based on the data type of the destination field. If the destination field is
a reference field to kb_knowledge, the platform creates a reference link to the existing
article rather than copying the article contents into the record.
Note:
• The target field must be on the form to receive the data.
• Optionally, you can specify more than one target field, separated by
commas. In this case, the platform looks for each field in order and copies
the contents into the first one it finds on the form. It does not copy the data
into multiple fields.
• If the selected field does not exist on the form, the platform automatically
checks for Comments and Description.
Procedure
1. Navigate to Knowledge > Properties.

2. In the Other Knowledge Properties section, locate the property that begins with When
attaching an article to an incident, problem, or catalog task, copy the article content into
the following field.
3. Specify a field into which to copy knowledge article content.
This entry must be the Element name for the field, which is found by right-clicking the
field name and selecting Configure Label.
By default, this property is set to comment, meaning that content is copied into the
Additional comments field. If you change the value to work_notes, the article content is
copied into the Work notes field.
Show flagged VIPs in the incident list

Organizations commonly designate VIP status in the user record for some of their VIP users.
The administrator can add the VIP field to the user record form to designate those users. If
the Incident list view is configured to display Caller, VIPs are visually flagged.
Before you begin
Role required: personalize_list or admin

About this task
When caller is assigned to an incident, the user record is automatically checked for VIP
status. In the incident form, an icon appears beside the name and the name displays in red.
VIP caller indication
If the Caller column does not display in the Incident list view, the column can be added.
Procedure
1. Perform the appropriate action for your list version.
Version Action
List v2 Right-click the Incident list header and select
Configure > List Layout.
List v3 Open the list title menu and select List Layout.
2. Add the Caller column to the Selected list.

3. Click Save.

VIP caller
Configure incidents to close automatically

Last updated: February 04, 2018
You can configure a system property to automatically close tickets that have been in
Resolved state for a specified number of days. You can also change the user who is assigned
by default in the Updated by field when an incident is automatically closed.
Before you begin
About this task
If the property is set to three days, then the incident is closed automatically three days after
the state is changed to Resolved. Any update to the incident restarts this three-day clock,
for example, when a user adds a comment. If you set this property to zero days, incidents do
not auto-close.
Note: You cannot auto close a major incident if the major incident is in the
Accepted state.
A scheduled job called Autoclose Incidents runs the Incident Autoclose business rule to
close incidents as described. By default, it assigns the name of the administrator who is
logged in when the Autoclose Incidents job runs.
Procedure
1. Complete the following steps to change the system property that sets the number of
days to auto-close incidents.
a. Navigate to Incident > Administration > Incident Properties.
b. Locate the property Number of days (integer) after which Resolved incidents are
automatically closed. Zero (0) disables this feature. (glide.ui.autoclose.time) and
enter the number of days.
c. Click Save.

If you have an inactivity monitor firing on your incident, it resets this auto-close clock
each time it fires, preventing your incident from being closed. To prevent this reset, put a
Reset Condition on your inactivity monitor of [Incident state] [is not] [Resolved].
2. Complete the following steps to change the default Updated by user for automatically
closed incidents.
a. Navigate to System Scheduler > Scheduled Jobs.
b. Open the Autoclose Incidents schedule.
c. Add fcRunAs=<user_name> to the Job context.
This code places System Administrator into the Updated by field.
fcRunAs=admin
fcScriptName =incident autoclose
Note: To avoid potential performance issues, ensure that the Incident Autoclose
business rule is set on the Incident [incident] table, not the Global
[global] table.
Related Concepts
• Incident resolution and closure
Create a UI action to close multiple incidents

You can create a UI action to close multiple incidents from the Actions choice list in the list
view. It adds the same close note to all the incidents being closed, and does not require the
list_updater role. Implementing this process also requires a business rule for the UI action to
reference and a custom form view.
Before you begin
business_rule_admin (for the business rule), ui_action_admin (for the UI action), or admin
Procedure
1. Complete the following steps to create the business rule to reference in the UI action.
a. Navigate to System Definition > Business Rules and click New.
b. Create the business rule with the following information.
• Name: close_it
• Table: Incident [incident]
• When: after
• Script: paste the following information.
current.active = 'false';
current.short_description = "TEST CLOSE NOTES";
current.incident_state = '7';
gs.addInfoMessage("Closing");
current.update();
c. Click Submit.
2. Complete the following steps to create the UI action.
a. Navigate to System UI > UI Actions and click New.
b. Create a UI action with the following information.
• Name: CloseNotes
• Table: Incident [incident]

• Action name: close_notes

• Active, Show insert, Show update, Client, List choice: Select these check boxes.
• OnClick: showQuickForm('CloseNotes','close_it')
c. Click Submit.
The new UI action appears in the Action choice list below the Incident list of records.
3. Complete the following steps to create a form view to use the UI action for closing
multiple incidents.
a. Follow the steps in Create a view and include the following information.
• In the Name, match the first parameter to showQuickForm() in the UI action. In
this example, the parameter is CloseNotes.
• Review and update the fields in the Selected list, ensuring that the Comments
and Work notes item is selected.
b. Save the CloseNotes view.
Result
Service desk agents can close multiple incidents using CloseNotes in the Actions list below
the Incident list.
Note: The showQuickForm() functionality is not applicable for List V3.
Related Tasks
• Close multiple incidents from the UI action
View incident notifications

You can view the incident notifications that are sent during specific events in an incident life
cycle. These notifications are sent to various recipients including ESS and ITIL users.
Before you begin
Procedure
1. Navigate to System Notification > Email > Notifications.

2. Filter the list of notifications by [Table] [is] [incident].
3. View the following list of default notifications for incidents.
Note: To receive these notifications, the end user must have notifications
enabled. For more information, see Subscription-based notifications.
Incident notification name Description Conditions of notification

Incident commented for ITIL Send notification to the ITIL Enter a comment in the
user only each time the incident form and save.
incident is commented upon.
Incident Opened and Send notification when an a. Subscribe a user to receive
Unassigned incident is opened but not Incident Opened and
assigned to any user. Unassigned notifications.
b. Create an incident without
assigning it.

Incident notification name Description Conditions of notification

Incident Closed Send notification to the caller Change the incident state to
when the incident is closed. closed. Provide closed notes
and close code.
Incident inactive Send notification to the user a. Set the notification to
the incident is assigned to and active=true.
the assignment group when b. Create an incident that
the incident becomes inactive. matches the conditions in
the SLA Inactivity monitor.
Note: This notification is c. Ensure that no activity is
inactive by default. performed on the incident
and the conditions do not
change for the duration
specified in the SLA
Inactivity monitor.
Incident Resolved Send notification to the caller Create an incident and change
when the incident is marked as the incident state to resolved.
resolved.
Incident assigned to my group Send notification when the a. Specify the Assignment
incident is assigned to the user group[assignment_group]
group. in the incident.
b. Leave the Assigned to
[assigned_to] blank.
Incident assigned to me Send notification when the Specify the Assigned to
incident is assigned to the user. [assigned_to] details.
Incident Escalated Send notification to a. Subscribe a user to receive
appropriate users each time Incident Escalated
the incident is escalated to a notifications.
value greater than the previous b. Create an incident.
one. c. Update the
Escalation[incident.escalation]
field to a value greater
than the previous value.
Incident commented Send notification each time the a. Subscribe a user to receive
incident is commented upon to Incident Commented
the notification subscriber only. notifications.
b. Enter a comment in the
incident form and save.
Incident opened for me Send notification when the a. Create an incident.
incident is opened on behalf of b. Change caller id.
the user.
Incident commented for ESS Send notification each time the Enter a comment in the
incident is commented upon to incident form and save.
the self-service user only.
4. Click the notification name to view the details of the incident.
Related Topics
• Create an email notification
Create trigger rules for major incidents


Create trigger rules to define conditions under which a trigger action is executed. You can
create major incident trigger rules to define conditions under which an incident is
automatically considered as a major incident candidate.
Before you begin
Role required: incident_manager or admin
About this task
Major incident trigger rules are evaluated asynchronously each time an incident is created or
updated provided the rules matches the following conditions:
• Incident record does not have parent incident populated i.e. the current incident is not a
child incident.
• Major incident is not in the Proposed or Accepted state.
• Incident is active.
Note: The base system major incident trigger rules are disabled by default.
Procedure
1. Navigate to Major Incidents > Administration > Major Incident Trigger Rules.
2. Click New.
3. Complete the required details in the form.
Field Description
Name Name of the trigger rule.
Execution Order The rule with lowest execution order is
triggered first. In the following example, the
rule with order = 100 is executed first.
Example:
• If business criticality of business service is
1-most critical or 2-somewhat critical, then
Order = 100.
• If the number of child incidents is greater
than 20, then Order = 200.
• For P1 incident, Order = 300.
Note: If any of the existing trigger rule

conditions is met, the incident is
considered to be a major
incident candidate and
verification of the remaining
rules are not required.
Otherwise, all the rules are
verified based on the execution
order.
Active Activates or deactivates a trigger rule when

selected or cleared.

Field Description
Trigger Conditions Conditions to be evaluated on an incident to
verify whether values in the incident satisfy the
trigger rule condition.
4. Define conditions to identify a major incident candidate.

5. Click Submit.
Activate Incident Management - Core

Incident Management - Core plugin (com.snc.incident_management) is a new incident state

model that includes demo data and activates related plugins if they are not already active.
About this task
Incident Management - Core (com.snc.incident_management) is available by default in new

instances but it is not available on upgrade. Customers upgrading from Geneva or earlier
versions must request the plugin. For more information, see KB0564465.
Note: If the new state model is installed on upgraded instances, then ensure that
the old states are mapped to the new ones. The mapping is especially
important if you have made customizations, implemented workflows, added
script includes, and added business rules.
Procedure
1. In the HI Service Portal, click Service Catalog > Activate Plugin.

2. Fill out the form.
Target Instance Instance on which to activate the plugin.

Plugin Name Name of the plugin to activate.
Specify the date and time you would like this Date and time must be at least 2 business days
plugin to be enabled from the current time.
Note: Plugins are activated in two

batches each business day in
the Pacific timezone, once in
the morning and once in the
evening. If the plugin must be
activated at a specific time,
enter the request in the
Reason/Comments.
Reason/Comments Any information that would be helpful for the

ServiceNow personnel activating the plugin
such as if you need the plugin activated at a
specific time instead of during one of the
default activation windows.
3. Click Submit.

• Installed with Incident Management - Core
Several types of components are installed with the Incident Management - Core plugin.
Related Topics
• List of Kingston plugins
Installed with Incident Management - Core

Several types of components are installed with the Incident Management - Core plugin.
Script includes installed with Incident Management - Core

Incident Management - Core plugin adds the following script includes.
Script includes
Script Include Description
IncidentStateSNC Defines out-of-the-box states for incident. The file is protected. If you
want to update the state values, use IncidentState.
IncidentState Defines incident state constants. Use this constant when determining
which incident state to use.
State model mapping

Describes how the incident states from the old state model map to incident states of the
new state model.
The old state model does not have the On Hold state. The new state model has three old
incident states that map to the new On Hold state. When the user selects the On Hold state,
a new field,On Hold Reason, appears.
Map old state to new state

Old incident state model New incident state model
New1 New 1
Active 2 In Progress 2
Awaiting Problem 3 On Hold 3
Awaiting User Info 4 On Hold 3
Awaiting Evidence 5 On Hold 3
Resolved 6 Resolved 6
Closed 7 Closed 7
Canceled 8

Scripts modified with Incident Management - Core

The Incident Management - Core plugin modifies the following script includes.
The following scripts have been updated to change the Incident management state model.
State values have been changed from hard-coded values to references to the IncidentState
script include.
The Incident state model is customizable for advanced users. The script include
IncidentState holds the base states that are used by the code to make state-based
decisions.
Script modified for incident form

Name Type Table
Caller Close Business rule sys_script
incident reopen Business rule sys_script
mark_closed Business rule sys_script
incident autoclose Business rule sys_script
Create Problem UI action sys_ui_action
Create Normal Change UI action sys_ui_action
Close Incident UI action sys_ui_action
Script modified for incident resolution workflow

Name Type Table
SNC - ITIL - Close Related Business rule sys_script
Note: This business rule is also

used in service
management.
SNC - ITIL - Resolve Related Incidents Business rule sys_script

Create Request UI action sys_ui_action
Script modified for incident resolution fields

Name Type Table
mark_resolved Business rule sys_script
Script modified for incident alert management

Name Type Table
Show Related Incident Alert UI action sys_ui_action
Create Incident Alert UI action sys_ui_action
Script modified for change request form

Name Type Table

Name Type Table

Create Emergency Change UI Actions sys_ui_action
Script modified for problem form

Name Type Table
Script modified for knowledge management

Name Type Table
Communicate Workaround UI action sys_ui_action
Script modified for service management functionality

Name Type Table
SNC - ITIL - Close Related Business rule sys_script
Activate Incident Management Best Practice – Kingston

Last updated: January 17, 2018
You can activate the Incident Management Best Practice - Kingston plugin
(com.snc.best_practice.incident.kingston) if you have the admin role. This plugin includes
demo data and activates related plugins if they are not already active.
Before you begin
About this task
Incident Management Best Practice - Kingston plugin

(com.snc.best_practice.incident.kingston) is available by default for the new customers.
Existing customers must Request a plugin .
Related Concepts
Related Topics
• List of plugins (Kingston)
Installed with Incident Management Best Practice – Kingston

Last updated: January 17, 2018
Several types of components are installed with the Incident Management Best Practice -
Kingston plugin (com.snc.best_practice.incident.kingston).

Properties installed with Incident Management Best Practice

Incident Management Best Practice - Kingston adds the following properties. These
properties are available at Incident > Administration > Incident Properties.
Note: To open the System Property [sys_properties] table, enter sys_properties.list in

the navigation filter.
Property Usage
List of all the task types where user wants to Lists all the Task types (e.g. incident,
associate CI's using a List change_request) where user wants to associate
com.snc.task.associate_ci Configuration Items (CIs) as a List.
• Type: String
• Default value: change_request, incident
Number of days (integer) after which Resolved Number of days (integer) after which Resolved
incidents are automatically closed. Zero (0) incidents are automatically closed. Zero (0)
disables this feature disables this feature.
glide.ui.autoclose.time
• Type: Integer
• Default value: 7
Data policy installed with Incident Management Best Practice

Incident Management Best Practice - Kingston adds the following data policy.
Data policy Description

Make close info mandatory when resolved or Ensures that the mandatory fields Resolution
closed code and Resolution notes are always populated
when an Incident is set to Resolved or Closed.
UI policy installed with Incident Management Best Practice

Incident Management Best Practice - Kingston adds the following UI policy.
UI policy Table Description

Make fields read-only on close Incident Makes fields on the Incident
[Incident] record read-only when the
Incident is closed or canceled.
Business rules installed with Incident Management Best

Practice
Incident Management Best Practice - Kingston adds the following business rules.
Business rule Table Description

Incident State Change to In Incident Sets the state of the Incident to
Progress [Incident] In Progress when the caller
updates an incident that is On


Hold and the on-hold reason is
Awaiting Caller.
Sync Child Incident State Incident Controls the entire Parent-Child

[Incident] Incident State synchronisation.
Note: The business rule SNC - ITIL - Close Related is deactivated when you activate
the plugin.
Email notifications installed with Incident Management Best

Practice
Incident Management Best Practice - Kingston adds the following email notifications.
Email notification Description

Incident commented and state changed Fired when an Incident state changes from On
Hold to In Progress. The recipients is the person
to whom the incident is assigned and the people
on the Watch List for that Incident.
Activate Incident Management - Major Incident

Management
You can activate the Incident Management — Major Incident Management plugin
(com.snc.incident.mim) if you have the admin role. This plugin includes demo data and
activates related plugins if they are not already active.
Before you begin
About this task
Incident Management - Major Incident Management plugin (com.snc.incident.mim) must be

manually activated for new and existing customers.
Incident Management - Major Incident Management plugin activates these related plugins if
they are not already active:
• Incident Alert Management (com.snc.iam)

• Incident Updates (com.snc.incident.updates)
• Task-Outage Relationship (com.snc.task_outage)
Plugins for Incident Management - Major Incident Management

Plugin Description
Notify Provides platform features for workflow-driven
voice calls, conference calls, and SMS messages
making it possible to create flexible Interactive

Plugin Description
[com.snc.notify] Voice Response (IVR) systems to do virtually
anything. Requires the Twilio Driver and a
separate contract with Twilio for SMS and Voice
capabilities.
On-Call Scheduling Provides the ability to create on-call schedules
[com.snc.on_call_rotation] and escalation trees. When an incident is created,
dynamically route the escalation to an on-call
resource. On Call allows you to configure and
build different on-call schedules per process and
assignment group.
Procedure
1. Navigate to System Definition > Plugins.

2. Find and click the plugin name.
3. On the System Plugin form, review the plugin details and then click the Activate/
Upgrade related link.
If the plugin depends on other plugins, these plugins are listed along with their
activation status.
If the plugin has optional features that depend on other plugins, those plugins are listed
under Some files will not be loaded because these plugins are inactive. The optional
features are not installed until the listed plugins are installed (before or after the
installation of the current plugin).
4. (Optional) If available, select the Load demo data check box.
Some plugins include demo data—Sample records that are designed to illustrate plugin
features for common use cases. Loading demo data is a good practice when you first
activate the plugin on a development or test instance.
You can also load demo data after the plugin is activated by clicking the Load Demo
Data Only related link on the System Plugin form.
5. Click Activate.
Several types of components are installed with the Incident Management - Major Incident
Management plugin.
Related Topics
• List of Kingston plugins
Installed with Incident Management - Major Incident Management

Several types of components are installed with the Incident Management - Major Incident
Management plugin.

Related Concepts
Tables installed with Major Incident Management

Incident Management — Major Incident Management adds the following table.
Table Description
Major Incident Trigger Rules This table extends the Application File
[major_incident_trigger_rule] [sys_metadata] table and stores the major
incident trigger rules.
Properties installed with Major Incident Management

Incident Management — Major Incident Management adds the following properties.
These properties are available at Incident > Administration > Major Incident Properties.
Property Usage
Create major incident from candidate Provides option to create a new major incident or
sn_major_inc_mgmt.com.snc.incident .min.major_incident_creation
to promote a major incident candidate to a major
incident.
Compose Email on Major Incident Overview Provides comma-separated list of Incident Alert
sn_major_inc_mgmt.com.snc.incident.mim.compose_email_on_iatasks
Task types that can have Compose Email option
on Major Incident Workbench.
Roles installed with Major Incident Management

Incident Management – Major Incident Management adds the following roles.
Role title [name] Description Contains roles

Major incident manager Initiates the major incident This role inherits the ia_admin
[major_incident_manager] process by assessing and role.
approving major incident
candidates or creating a major
incident. Maintains the
ownership and accountability for
the life cycle of the incident.
Identifies the users and groups
to be involved in the resolution
activities and sets up
communication channels. Major
incident manager also has the
ability to close incident only if
the Major incident state of the
incident is Accepted and the
Incident state is Resolved.
Communication manager Manages communication for This role inherits the ia_admin
[communication_manager] major incidents and is role.

Role title [name] Description Contains roles

responsible for communicating
with all stakeholders.
Incident Manager Manages incident properties and None
[incident_manager] major incident trigger rules.
(Existing role with added

responsibilities)
Script includes installed with Major Incident Management

Incident Management – Major Incident Management adds the following script includes.
Script include Description

MajorIncidentTriggerRulesSNC All the methods needed for Major Incident
Management flows. This script cannot be
modified by customers as it is write protected.
MajorIncidentTriggerRules All the methods needed for Major Incident
Management flows. This script can be modified
by customers.
Business rules installed with Major Incident Management

Incident Management – Major Incident Management adds the following business rules.

Evaluate Major Incident Trigger Incident This business rule runs
Async Incident [Incident] asynchronously against the
incident table and automatically
creates a major incident
candidate if the major incident
trigger criteria mentioned in the
Major Incident Trigger Rules
[major_incident_trigger_rule]
table matches with any of the
incident condition.
Major incident state has Incident When major incident is
changed Incident [Incident] accepted, this business rule
helps to capture information
about who has accepted the
major incident candidate to be a
major incident and at what
date/time.
Email notifications installed with Major Incident Management

Incident Management – Major Incident Management adds the following email notifications.
Email notification Description

Major Incident Candidate Assigned Major incident candidate is assigned to a major
incident manager for his approval.
Major Incident Candidate Rejected Major incident candidate is rejected by major
incident manager.

Create an incident
When a user calls or walks in to the service desk, the ITIL agent can log an incident from the
Incident list.
Before you begin
Role required: itil
About this task
Incidents are also logged when a user fills out a record producer in the service catalog, or
sends an email to the instance. This procedure describes how an ITIL agent completes the
Incident form.
Procedure
1. Navigate to Incident > Create New.

You can also click New from the Incident list view.
2. (Optional) Use a template, if one exists for the type of incident you are logging.
If the organization uses form templates, you can apply a template to prepopulate some
of the fields for specific types of incidents.
3. Complete the form.
Your organization has configured the Incident form to adhere to its incident
management process. Enter information in the form field based on the process. The
following table describes typical Incident form fields.
Field Description
Number Unique system-generated incident number.
Caller The user who contacted you with an issue. Begin typing
the first name of the caller to select from a list of
matching names, or click the lookup icon and select the
user.
Category and Subcategory The type of issue. After selecting the category, select
the subcategory, if applicable.
Business service The affected business service, if applicable.
If you select a business service as the configuration item
and that business service is also listed as the
configuration item in any other active task, the active
tasks icon ( ) appears. Click to view the

list of all the other active tasks that are affecting the
business service.
Configuration item The affected CI, if applicable.

After a CI is selected, you can click the open
dependency views icon beside the field to see how the
CI maps into the infrastructure. The dependency view
shows you what is impacted and whether other CIs or
services are experiencing issues.

Field Description
State The state moves and tracks incidents through several
stages of resolution.
For more information, see Incident Management state
model.
Impact The effect that the task has on business.

Urgency The extent to which the task resolution can be delayed.
Priority How quickly the service desk should address the task.
Assignment group and Assigned to The group and user to work on this incident. If left blank,
the incident is automatically assigned.
Short description A brief description of the incident.
Description Detailed explanation on the incident.
Notes section
Watch list Users who receive notifications about this incident when
comments are added. Click the add me icon to add
yourself to the watch list.
Work notes list Users who receive notifications about this incident when
work notes are added. Click the add me icon to add
yourself to the work notes list.
Note: The administrator must add or activate

an email notification for the work notes
list.
Additional comments More information about the issue as needed. All users
who can view incidents see additional comments.
Work notes Information about how to resolve the incident, or steps
taken to resolve it, if applicable.
Related Records section
Problem Information on any related problem record that is
related to the incident.
Change Request Information on any related change request.
Caused by Change Information on the change request that resulted in the
creation of the incident.
Resolution Information section
This section is only filled when an incident is resolved.
Knowledge If the check box is selected, a knowledge article is

created from this incident when it is closed.
Resolution code Document how an incident is resolved.
Resolution notes Information about how or why the incident was closed.
Resolved by The user who resolved the issue and the date and time
the incident was closed.
Resolved The date and time when the incident was resolved.
4. Click Submit.

Note:
To mail the incident record, click in the title bar and select Email.
The user who requested the incident and the user who is assigned to the
incident are automatically populated in the list of recipients.
• Use a template in the Incident form
You can apply a template to a new record when the prepopulated information is
applicable to the task you are creating.
• Log an incident through Self-Service
All users can log incidents through the Service Catalog or from the Incidents module in
Self-Service.
• Copy an incident or create a child incident
Copy Incident copies the details of an existing incident record to a new incident record.
Create Child Incident copies the details of the parent incident and links the new incident
to the parent incident.
Related Concepts
Related Reference
Use a template in the Incident form

You can apply a template to a new record when the prepopulated information is applicable
to the task you are creating.
Before you begin
Role required: itil
About this task
Many forms allow you to create a template for any type of record that you create frequently.
Open the more options menu to see whether templates are allowed.
Procedure
1. Open the Incident form to enter a new record.

2. To use a template, click the more options icon and select Toggle Template Bar.

Apply an incident template
3. Select the desired template from the list that appears in the template bar.
The template is applied and a message at the top provides a link to look at the details of
the fields you populated.
4. (Optional) To undo the changes made by the template, for example, if you selected the
wrong template, click Undo Changes in the details.
Related Tasks
Log an incident through Self-Service

All users can log incidents through the Service Catalog or from the Incidents module in Self-
Service.
Before you begin
Role required: none
About this task
You log an incident when you experience a disruption to normal service operations. You can
specify the urgency and monitor the progress through to resolution.
How to report issues through the service catalog and service
portal, explains that the system automatically generates

incidents from issues, and shows how to track your open

incidents.
Procedure
1. Navigate to an incident form by using one of the following methods.
Option Description
Service Catalog a. Navigate to Self-Service > Service Catalog.
b. Click Can We Help You?
c. Click Create Incident.
Self-Service a. Navigate to Self-Service > Incidents.

b. Click New.
2. Select the urgency level of the issue in the Urgency choice list.
3. Describe the nature of the issue in the Please describe your issue below text box.
4. Click Submit to log the incident.
The Incident form with the incident details appears.
What to do next
As the incident is investigated and resolved, you can take any of the following actions.
Manage your incidents

Action What to do
Track the progress of the incident Track the progress of your incident from on the
incident number and from your homepage. You
can also choose to receive notification each time
an update is made to the incident.
Update the incident Update an incident by entering additional details
in the Additional Comments field.
Reopen a closed or canceled incident You cannot reopen a closed or canceled incident.
If you are not satisfied with the resolution, you
can request to reopen the incident from the

Action What to do
resolution notification email or from the incident
itself. The state of the incident is then changed
from Resolved to In Progress.
Note: If the incident is already closed,

you can reopen it by replying to
any email related to that incident.
Add the text Please reopen to the
subject line. A new incident is
opened and the original incident
is identified as the source.
Related Tasks
Copy an incident or create a child incident

Copy Incident copies the details of an existing incident record to a new incident record.
Create Child Incident copies the details of the parent incident and links the new incident to
the parent incident.
Before you begin
Role required: itil
Note: An itil user can copy or create any incident whereas an ess user can copy
only the incident that he or she has created.
Procedure
1. Navigate to Incident > Open.

2. Open the existing incident that you want to copy or from which you want to create a
child incident.
3. Do any one of the following actions:
• To copy an incident, click and then click Copy Incident.
Note: After the incident is copied, the Work notes field is updated with the
following message: Created from a similar incident: INTXXXXXX.
• To create child incident, click the Child Incidents tab in the related list and then click
Create Child Incident.

Note: Ensure that you have Incident -> Parent Incident related list and the
Parent Incident field is added to the incident form. The incident from
which you have created the child incident is the parent incident for
the child incident.
4. Fill out the other fields, as required.
5. Click Submit.
The default fields and related lists that are copied from the parent incident are:
• Fields:
Category
Subcategory
Business Service
Configuration item
Impact
Urgency
Assignment group
Short Description
Description
Related lists
Caused by Change
Location
Company
Problem
Change Request
Parent incident
Note: If the problem, change, or the parent incident is not active, then
details of those fields are not copied.
• Related lists:
Affected CIs
Impacted Services
Related Tasks
Work on incidents
Working on incidents involves diagnosing and investigating the incident, recording results,
and sometimes escalating or promoting the incident.
Initial diagnosis of incidents is largely a human process. The service desk agent looks at the
details of the incident and communicates with the user to diagnose the issue.
To aid in the diagnosis, the service desk agent can consult the configuration management
database, or CMDB. The CMDB contains information about hardware and software within a
network and the relationships between them. The CMDB can be populated in two ways:
Discovery and Help the Help Desk . Discovery is available as a separate product, but Help
the Help Desk is provided with the base system.

Incident investigation
Incident investigation is also a human process. The service desk continues to use the
information in the Incident form and the CMDB to solve the issue. Work notes are added to
the incident as it is evaluated, facilitating communication between the concerned parties.
Work notes and other updates can be communicated to the concerned parties through
email notifications.
One way to investigate incidents is to determine whether related records exist, using one of
the following features.
Related incidents icon
The show related incidents icon ( ) appears beside the Caller field when it is populated.
Click it to open a popup window and review a list of incidents for same caller.
Note: Administrators can add this icon to any reference field by modifying the
dictionary entry and adding the ref_contributions=user_show_incidents
dictionary attribute. The icon appears only for users who have read or write
access to the field. A UI macro named user_show_incidents defines the
behavior. The UI macro must be active to view the related incidents icon.
Incidents by Same Caller related list
Another way to research related incidents is to use the Incidents by Same Caller related list.
The administrator may need to configure the form to display this related list.
Dependency views
Dependency views can help find related incidents based on configuration items (CI). If a
configuration item is attached to an incident, click the map icon ( ) to display the
dependency views map. To view tasks attached to the CI, click the down arrow next to the
CI and select View Related Tasks.
CI options

Incident promotion
When the incident management team has determined that the cause of an incident is an
error or widespread problem, the team initiates the problem management process. When
the issue requires a change to the infrastructure or a business service, the team initiates the
change management process.
A menu item on the Incident form lets you create a problem or change record and associate
the incident with the problem or change record. In this way, incidents can be used to easily
create problems or changes.
Note: If the incident already has an associated problem or change record, you
cannot promote an incident to a record of that type.
Sometimes the resolution for the user is to request hardware or software for them. For
example, a user may report a problem that requires a new mouse device or keyboard. The
service desk agent can create a request from the incident. The incident is associated with
the requested item.
release.
Incident escalation
There are two escalation methods the platform uses to track and report on incidents that
are not being resolved according to your organization standards.
Service level agreements (SLAs)
SLAs monitor the progress of an incident according to defined rules. As time passes, the
SLA escalates the Priority of the incident, and leaves a marker as to its progress. SLAs are
also used as a performance indicator for the service desk.
Inactivity monitor
The inactivity monitor generates an event to prevent incidents from going unnoticed. When
a certain amount of time has passed without an update to the incident, the event creates an
email notification or triggers a script.
After an incident is added, it is reviewed to ensure that it is properly categorized and

prioritized.
• Use a dependency view to locate affected CIs
The service desk can use dependency views to identify CIs that are affected due to a
configuration item that has caused an incident.
An incident can be promoted to a problem, request, or change.

• Create a knowledge article from an incident

When you are ready to close an incident, you can create a knowledge article so the next
time the issue comes up the resolution is easy to find.
A major incident (MI) is an incident that results in significant disruption to the business
and demands a response beyond the routine incident management process. Major
incidents have a separate procedure with shorter timescales and urgency that is required
to accelerate resolution process for incidents with high business impact.
The major incident workbench is a single pane view designed for major incident
managers, communication managers, and resolver groups to manage major incidents by
aggregating and providing actionable information.
Assign and update incidents

After an incident is added, it is reviewed to ensure that it is properly categorized and

prioritized.
Before you begin
Role required: Itil, itil_admin, or admin
About this task
When you view an incident, you can see whether another user or users are viewing or
updating the incident at the same time. For more information, see User presence.
Procedure
1. To view incidents, navigate to Incidents and click the type of incident list to view.
For example, click Open-Unassigned to see the list of incidents that do not have anyone
working on them.
The Incident list view displays several columns, including Number, Category, Priority,
Incident state, and Assigned to. You can personalize the list to add more columns. For
example, to see who resolved the incident, add Resolved by.
2. (Optional) To filter the list, use a quick filter or create a more detailed filter query.
For example, you can filter for all high-priority or critical incidents.
3. Open the incident to assign or update and perform any of the following actions.
Option Description
Assign a group Click the lookup icon beside Assignment group
and select the group. Selecting an assignment
group narrows down the selection of users you
can assign. Only members of the group are
available.

Option Description
Note: The sys_user_group read ACL
calls the SNCRoleUtil function.
The function checks to see
whether the group being
reviewed contains either the
admin role or security_admin
role. The function allows the
user to view the group only if
the user has the same role. As a
result, an itil user cannot assign
an incident to a group that has
the admin role or
security_admin role. Nor to one
whose parent has the role.
Assign a user Click the lookup icon beside Assigned to and

select the user. If the Assignment group
changes, the Assigned to field is cleared.
Note: This feature is available only for

new instances, starting with the
Jakarta release.
Categorize the incident Select values from the Category and

Subcategory fields, as appropriate.
Change the Impact or Urgency Select the Impact or Urgency values based on
your organizational guidelines. Changes to
these fields can update the Priority field based
on incident data lookup rules.
Add a configuration item (CI) Configuration items identify the service or item
that is experiencing trouble.
4. Click Update.
Related Tasks
Related Concepts
Use a dependency view to locate affected CIs


The service desk can use dependency views to identify CIs that are affected due to a
configuration item that has caused an incident.
Before you begin
Role required: Itil, itil_admin, or admin
About this task
Often, an incident is related to one or more specific configuration items (CIs). If the
configuration management database (CMDB) is populated, the CI records hold valuable
information to help resolve incidents. You can associate configuration items to an incident to
see how the incident affects dependent CIs.
Procedure
1. In the Incident form, complete one or both of the following steps to associate CIs.
To use the Do the following

Configuration item reference field Click the lookup icon beside the field and
select the CI.
Affected CIs related list Click Edit at the top of the list. Select the CI to
associate, and click Save.
If necessary, the administrator can configure
the form to display the Affected CIs related list.
Use the Configuration Item field when a single CI is the cause of the incident, and the
Affected CI's related list when multiple CIs are affected by the incident.
For example, suppose a load-balancer in a datacenter is no longer operational. The
Configuration Item field lists the specific server which is out of memory. The Affected CI
related list contains the load-balancer, the datacenter, the servers that depend on the
load-balancer, and business services that are impacted by the missing server.
2. To see more information, click the dependency views icon ( ) beside the
Configuration item field.
The Dependency Views map opens in a new tab or window.
3. To see items that this CI affects, click the down arrow and select View Affected CIs.
The CIs Affected list opens in a new tab or window.

4. To add another affected CI to the incident, click the down arrow beside the CI and click
Add Affected CI(s).
The selected CI is added to the incident.

Related Tasks
Related Concepts
Related Topics
• Dependency Views map
Promote an incident
An incident can be promoted to a problem, request, or change.
Before you begin
Role required: itil, itil_admin, or admin
About this task
When the cause of an incident is an error or widespread problem, the incident is promoted
to a problem. When the issue requires a change to the infrastructure or a business service,
the incident is promoted to a change.
An incident is promoted to a request when the resolution for the user is to request hardware
or software.
Procedure
1. Open the incident to promote.

2. Open the form context menu and select the appropriate option.
To promote the incident to a Select

Problem Create Problem.
Request Create Request.
Change Create Normal Change or Create Emergency

Change.
The form for the new record appears and has been saved. Particular fields are copied to
the promoted record from the incident.
3. Complete the Problem, Request, or Change form with additional information.
4. Click Update.
The promoted record is saved. The incident is cross-referenced to the problem, change,
or request as follows:

Incident promoted to Incident form reference Promoted form reference

Problem Problem field in the Related Incidents Related list in the
Records section. Problem form.
Request Requests Related list. This Parent field in the Request
related list is hidden unless form. If necessary, the
there is an associated request. administrator can configure
If necessary, the administrator the Request form to display
can configure the Incident the Parent field.
form to display the Requests
related list.
Note: This feature is

available only for
new instances,
starting with the
Jakarta release.
Change Change Request field in the Incidents Fixed by Change

Related Records section. Related list in the Change
Request form.
The following images illustrate the Incident form references for incidents promoted to a
problem, change, or request.
Related Tasks
Related Concepts

Related Reference
• Incident promotion UI actions
Create a knowledge article from an incident

When you are ready to close an incident, you can create a knowledge article so the next
time the issue comes up the resolution is easy to find.
Before you begin
Role required: itil
About this task
When an incident is closed either by the caller or automatically, a draft knowledge article is
created.
Procedure
1. Open a resolved incident that you want to close.

2. Ensure that the Knowledge check box is selected and that a resolution is entered in the
Additional comments (Customer visible) field.
3. Click Close incident.
A new draft knowledge article is created. The content in the fields listed in the following
table is copied from the Incident form to the Knowledge form.
Field on Incident form Field on Knowledge form

Short description Short description
Additional comments Text
Number Source
The Knowledge related list on the Incident form is populated with the new draft
knowledge article. The draft article does not appear in the knowledge base (KB) for
users until it is reviewed and published.
If the knowledge submission workflow is enabled, the comments in the incident Short
description and Additional comments fields become a knowledge submission instead of
an article. The KB Submissions related list on the Incident form is populated with the
new knowledge submission. For more information, see Knowledge workflows .
What to do next
To see the draft articles, navigate to Knowledge > My Knowledge Articles and then open the
draft article by its KB number in the Knowledge form.
Related Tasks

Related Concepts
Major incident management

A major incident (MI) is an incident that results in significant disruption to the business and
demands a response beyond the routine incident management process. Major incidents have
a separate procedure with shorter timescales and urgency that is required to accelerate
resolution process for incidents with high business impact.
The definition of what constitutes a major incident must be determined and agreed upon.
For example, a major incident could be created if a critical business service is impacted or if
there is a service outage that affects a large number of users.
You can also create a new major incident candidate by clicking Create Major Incident
Candidate from the left navigation pane. The major incident manager then analyses the
candidate and decides whether a major incident is at all required. The Create major incident
from candidate property
(sn_major_inc_mgmt.com.snc.incident .min.major_incident_creation) provides option to
create a new major incident or to promote a major incident candidate to a major incident.
Note: The base system major incident trigger rules are disabled by default. You
need to activate the trigger rules that define conditions under which an
incident is automatically considered as a major incident candidate.
When you create a new major incident from a candidate, a new incident is created and
becomes the major incident. The candidate is added as the child of the major incident. The
major incident is automatically assigned to the Major Incident Management group. System
automatically assigns the newly created parent major incident to a user when the On-Call
Scheduling plugin (com.snc.on_call_rotation) is activated, a rota is defined for the major
incident management group, and a user is available for the on-call rota. If no on-call rota
exists, the major incident manager decides the user for the Assigned to field.
When a major incident candidate is promoted as a major incident, the incident itself is
considered as a major incident. There is no new incident that is created. The value in the
existing Assignment group or the Assigned to field does not change to the major incident
management group or any user. The major incident manager needs to reassign the value of
the fields as appropriate.
Propose an incident as a major incident candidate

An incident is proposed as a major incident candidate or a new major incident candidate is

created so that a major incident manager can evaluate the candidate and decide whether a
major incident is necessary.
Before you begin
Role required: itil
You can process an incident as a major incident candidate in the following ways:

• Applying major incident trigger rules: An existing incident can be converted to a major
incident candidate based on the Create trigger rules for major incidents.
• Proposing an incident as a major incident candidate manually: You can manually propose
an existing incident to be a major incident candidate by clicking Propose Major Incident
from the context menu.
• Creating a candidate from the application navigation: You can create a new major incident
candidate by clicking Application > Incident > Major Incidents > Create Major Incident
Candidate.
When an incident is proposed as a major incident candidate, the Major incident state field in
the incident form under the Major incident tab is changed to Proposed.
Related Reference
• Incident management properties
Accept or Reject a Major Incident Candidate

When an incident is proposed as a major incident candidate, the Major Incident Manager can
accept or reject the candidate.
Before you begin
Role required: major incident manager
About this task
If a major incident manager approves, the incident is promoted to a major incident and the
Major incident state field in the incident form under the Major incident tab is changed from
Proposed to Accepted. Also, the View Workbench button appears on the header of the
incident form. The View Workbench button takes you to a single pane view designed for
major incident managers, communication managers, and resolver groups to manage major
incidents. If the major incident manager rejects the candidate, the incident remains as is and
the Major incident state field is changed to Rejected.
Note: If a major incident candidate is rejected, a notification is sent to the

assignment group associated to the incident.
A major incident manager can create a major incident in the following ways:
• Promote a major incident candidate to a major incident: On the form context menu, click
Promote to Major Incident.
• Create a new major incident: Navigate to Application > Incident > Major Incidents > Create
Major Incident.
Note: When you create a new major incident, the candidate becomes the child of
the newly created major incident. The Create major incident from candidate
property
(sn_major_inc_mgmt.com.snc.incident .min.major_incident_creation)
provides option to create a new major incident or to promote a major
incident candidate to a major incident.

Major incident workbench

The major incident workbench is a single pane view designed for major incident managers,
communication managers, and resolver groups to manage major incidents by aggregating
and providing actionable information.
To navigate to major incident workbench, click View Workbench that appears on the header
of the Incident form.
Note: The View Workbench button appears only when an incident is accepted as a
major incident.
The major incident workbench has three tabs: Summary, Communication, and Conference.
Note: Notify must be activated for the Conference tab to appear.
Use the chat icon ( ) on the header bar to initiate a chat on the major
incident level. The chat is a record feed — whatever you write in the chat
appears in the activity stream.
Major incident workbench
Major incident workbench UI elements

# UI element Description
1 Summary tab Provides a unified view of
relevant information, such as
child incidents, affected CIs,
impacted services, active
outages to assess and resolve
incidents. To add child incidents,
affected CIs, or impacted
services, click + on the
appropriate card header.
2 Communication tab Provides update on the progress
of restoration efforts by sending

targeted business and technical
communication.
Under the Communication tab,
on the left, you have the alerts
that are created for each major
incident – Technical Resolution
and Business Communication.
Each alert has a set of pre-
defined incident alert tasks that
are created with Flow Designer .
For each alert, you can find the
alert tasks under the Information
tab. You have the option to
Compose Email, View Task, and
Close Task.
You also have the Activity tab to

get a history of activities
performed for the alert. The
Email Log tab provides you with
the email exchanges that
happened during the life cycle
of the Incident alert. To initiate
chat at the alert level, click the
chat icon that appears beside
the Email Log. The chat initiates
a record feed.
Note: When you initiate a

chat, all members
defined in the user
group and group
contacts for the
alert are added
automatically with
your name as the
person who has
added them. Group
contacts are added
only when On-Call
Scheduling is
activated. To add
more participants
to the chat once it
is initiated, click the
add user ( )
icon.
3 Conference tab Provides option to initiate

technical and business
conference calls in parallel to
mobilize technical teams for
incident diagnosis and
resolution, and keep key
stakeholders informed. You can

click Initiate Conference Call,
add participants, and click OK to
initiate the call. Any participant
can rejoin the call by clicking
Join Conference Call. For more
information on conference
calling, refer to Notify .
4 Create Child Incident Creates a child of the major
incident.
5 Create Outage Creates an outage and opens an
outage form to complete the
necessary fields. For instant
start or end of an outage, you
can click the Begin Outage Now
or the End Outage Now related
links in the Outage form.
Note: The outage record

that you create
automatically
creates a task
outage that links
the outage with the
current major
incident.
6 View Form Returns you to the major

incident form.
Related Tasks
Related Concepts
Incident resolution and closure


After the incident is considered resolved, the service desk sets the incident state to
Resolved. When the incident is resolved, the escalators are stopped, and the caller can
review the resolution. If the caller is satisfied with the resolution, caller can close the incident
or the incident state is changed to Closed after sufficient time has passed.
If the cause of an incident is understood but cannot be fixed, the service desk can promote
the incident to a problem. The problem is evaluated through the problem management
process. If the incident creates the need for a change in IT services, the service desk can
generate a change from the incident, which is evaluated through the change management
process.
In addition to the base system incident management workflow, a Best Practice - Incident
Resolution Workflow is activated in your instance. This workflow brings the process into
better alignment with ITIL v3.
Incident closure
Incidents that were promoted to a problem can be configured to close automatically when
the problem is closed. This action is accomplished through business rules. Closed incidents
remain in the system for reference purposes. They can be viewed by navigating to Incident >
All.
It is also possible to generate customer satisfaction surveys when incidents are closed.
Surveys allow the service desk to gather information about their quality of service directly
from the user.
The Resolution Information section of the incident form contains details of who, when, and
why the incident was closed.
Resolution Information fields

Field Description
Knowledge If the check box is selected, a knowledge article is created in
Draft state when the incident is closed. This action is
accomplished with a business rule. Creating a knowledge
article can reduce the number of repeat incidents by
distributing the information related to the incident.
Resolution code Provides information on how the incident was resolved. The
field becomes mandatory when the incident state changes to
Resolved.
Resolution notes Notes added by the user who closed the incident. The field
becomes mandatory when the incident state changes to
Resolved.
Resolved by Automatically populated with the user who resolved the
incident.
Resolved Automatically populated with the date and time that the
incident was resolved.
Note: When the state of an incident changes to any state other than Resolved,
Closed, or Cancelled, the Resolved by, Resolved, Resolution code, and
Resolution note fields are cleared. System administrator can modify the
conditions on the Clear Resolve fields business rule if a different state model
is implemented, or deactivate the business rule as per the requirement.
• Best Practice - Incident Resolution Workflow

The Best Practice - Incident Resolution Workflow provides an ITIL-based workflow to

power the resolution of incidents.
• Close multiple incidents from a list
Service desk technicians with the list_updater role can close multiple incidents from an
incident list and attach the same close notes to all of them.
• Close multiple incidents from the UI action
The administrator can create a UI action to add an entry to the Actions choice list below
the Incident list. If this configuration is available, service desk agents can close multiple
incidents from the Incident list without the list_updater role.
Related Tasks
• Configure incidents to close automatically
Best Practice - Incident Resolution Workflow

The Best Practice - Incident Resolution Workflow provides an ITIL-based workflow to power
the resolution of incidents.
Incident resolution guidelines suggest that instead of closing the incident, the service desk
sets the incident state to Resolved. This state provides a mechanism to verify that the caller
is satisfied with the resolution and agrees with closing the incident. This workflow is
automatically activated on instances.
Note: Use this plugin to build a workflow (it does not install a workflow).
Incident resolution workflow
Resolve incident
Users with the itil_admin role have the capability to resolve as well as close incidents
whereas users with the itil role have the capability to resolve incidents with no option to
close. Users with itil role sees a Resolve Incident button toward the top of the form as well
have the option to select Resolved from the State choice list.

State choice list
Incident closed email notification

If an incident is closed, an email notification is sent to the ESS user.
Incident closed email notification
Reopen incidents
• Closed incidents are read-only for non-administrators.
• Incidents can only be reopened by users with the admin role.
• Users with the itil role cannot reopen closed incidents.
• ESS users have a Reopen Incident button on resolved Incidents.
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
atfields are populated.

Required fields
You cannot set the value of the State field in an incident to Resolved or Closed without
providing values for mandatory fields like Resolved Code and Resolution Notes, Close Code,
and Close Notes.
Resolve incident email notification

When an incident state is set to a Resolved, an email notification is sent to the caller. If the
caller is satisfied with the resolution, no action is required on behalf of the caller. The
platform automatically closes the incident after 24 hours.
If the caller is not satisfied, the caller can click the link in the email notification to reopen the
incident. This opens a reply email message to reopen the incident. The user can add
additional remarks to the email reply if necessary. The resolved incident is automatically
reopened and displays an In Progress state.
Auto-close in 24 hours
If the incident state is Resolved, and the caller has not emailed any feedback within 24
hours, the incident is auto-closed by a scheduled job. No information is added in the Closure
information fields. The duration of the auto-close function can be modified.
Caller closes incident

When a caller closes an incident, the following actions occur.
• A message with a link to the incident appears.

• A business rule automatically sets the Resolution notes and the Resolution code field
values.
Change the duration of the incident auto-close function

You can set a system property to change the duration of the incident auto-close function.
Before you begin
Procedure
1. Navigate to System Properties > UI Properties.

2. In the Number of days (integer) after which Resolved incidents are automatically closed.
Zero (0) disables this feature. property, enter a number of days.
3. Click Save.
What to do next
Update the resolved incident email notification text to reflect the new duration.
Update the resolved incident notification template

You can modify the contents of the email template used to generate the notification that an
ESS user receives when the service desk resolves an incident.

Before you begin
Procedure
1. Navigate to System Policy > Templates.

2. Select the incident.ess.resolve template.
3. Manually update the template content.
4. Click Update.
Close multiple incidents from a list

Service desk technicians with the list_updater role can close multiple incidents from an
incident list and attach the same close notes to all of them.
Before you begin
Role required: list_updater
About this task
The administrator can also configure an action to appear in the Actions choice list below the
list, and make it available to users without the list_updater role. For more information, see
Create a UI action to close multiple incidents.
Procedure
1. Select the check box beside each incident to be closed.

2. Perform the appropriate action for the version of lists.
Option Description
List v3 Open the list title menu and click Update
Selected.
List v2 Right-click any list column header and click

Update Selected.
The Incident form appears.

3. Set the State to Closed.
4. Select a Resolution code and enter notes in the Resolution notes field.
5. Click Update.
The changes apply to all the selected records.
Close multiple incidents from the UI action

The administrator can create a UI action to add an entry to the Actions choice list below the
Incident list. If this configuration is available, service desk agents can close multiple incidents
from the Incident list without the list_updater role.
Before you begin

Role required: itil, itil_admin, or admin
Procedure
1. Navigate to Incident > Open.

2. Select the check box beside each incident to be closed.
3. Select CloseNotes in the Action choice list below the list.
4. Set the State to Closed, select a Resolution code, and enter notes in the Resolution
notes field.
5. Click Update.
Related Tasks
• Create a UI action to close multiple incidents
Incident monitoring and tracking

Service desk and other IT managers can use homepages and reports to monitor and track
incident status and service levels.
Incident Overview
The Incident > Overview homepage provides a quick glance at the current state of open
incidents. At the top, single score widgets enumerate the open incident statuses, such as
critical incidents, unassigned incidents, and overdue incidents. Charts in the homepage
group incidents by factors such as priority and state. The incident overview is fully
interactive and configurable.
Critical Incidents map

The Incident > Critical Incidents Map module displays a map with symbols representing
every open critical incident. Use it to help allocate resources to work on the incidents. You
can point to a symbol to see the incident number or click a symbol to view the
corresponding incident.
Incident reports
Various incident reports are available in the base system, and you can modify the existing
reports or create new ones. Navigate to Reports > View / Run and enter incident in the
search box to view all incident reports. Base system reports include the following:
• Basic bar or pie chart reports, such as incidents by assignment group, location, priority, or
state. These reports help you analyze a specific data point, for example, whether enough
staff is allocated to an assignment group.
• Time series reports, such as Incident Trend by Configuration Item. This report lets you
analyze closed incidents by configuration item (CI) to identify potential problems.
• Multidimensional reports, such as Incidents by Priority and State older than 30 Days. This
report can help you identify gaps in service levels. For example, if a high number of low-
priority incidents are still in New state after being open more than 30 days.

Complimentary Performance Analytics for Incident

Management
Complimentary Performance Analytics for Incident Management and aggregates data over
time, and is enabled by default for Incident Management. Complimentary Performance
Analytics for Incident Management provides an Incident Management dashboard with 15
indicators to help you assess organizational performance. For more information, see
Performance Analytics for Incident Management .
If you subscribe to Performance Analytics, additional Out-of-the-box Performance Analytics

Solutions and in-form analytics are available for Incident Management. Out-of-the-box
Performance Analytics Solution for Incident Management contain preconfigured
dashboards. In-form analytics allow you to access preconfigured dashboards from the
Incident form.
Related Topics
• Homepage administration
• Report types and creation details
Out-of-the-box Incident Management Performance Analytics

Solutions
Performance Analytics Solutions and in-form analytics contain preconfigured best practice
dashboards. These dashboards contain actionable data visualizations that help you improve
your business processes and practices.
Note: You can activate Performance Analytics solutions and in-form analytics on
instances that have not licensed Performance Analytics to evaluate the
functionality. However, to start collecting data you must license Performance
Analytics.
Performance Analytics Solutions

Use the Performance Analytics widgets on the dashboard to visualize data over time,
analyze your business processes, and identify areas of improvement. With solutions, you can
get value from Performance Analytics for your application with minimal setup.
Note: Solutions include some dashboards that are inactive by default. You can
activate these dashboards to make them visible to end users according to
your business needs.
To enable the solution for Incident Management, an admin can navigate to Performance
Analytics > Guided Setup. Click Get Started then scroll to the section for Incident
Management. The guided setup takes you through the entire setup and configuration
process.

In-form analytics
A dashboard with relevant visualizations appears as a pop-up window when a user clicks the
Analytics icon ( ) next to a field. For example, in-form analytics on an incident form
show the expected time to close that incident based on historical data, enabling support
engineers to set appropriate customer expectations.
To enable the in-form analytics plugin for Incident Management, an admin can navigate to
System Definitions > Plugins and activate the Performance Analytics - Context Sensitive
Analytics for Incident plugin.
Related Topics
• Available solutions
• Solutions and in-form analytics
• Performance Analytics
Out-of-the-box Incident SLA Management Performance Analytics

Solutions
Performance Analytics Solutions contain preconfigured best practice dashboards. These

dashboards contain actionable data visualizations that help you improve your business
processes and practices.
Note: You can activate Performance Analytics solutions and in-form analytics on
instances that have not licensed Performance Analytics to evaluate the
functionality. However, to start collecting data you must license Performance
Analytics.
Performance Analytics Solutions

Use the Performance Analytics widgets on the dashboard to visualize data over time,
analyze your business processes, and identify areas of improvement. With solutions, you can
get value from Performance Analytics for your application with minimal setup.
Note: Solutions include some dashboards that are inactive by default. You can
activate these dashboards to make them visible to end users according to
your business needs.
To enable the solution for Incident SLA Management, an admin can navigate to Performance
Analytics > Guided Setup. Click Get Started then scroll to the section for Incident SLA
Management. The guided setup takes you through the entire setup and configuration
process.
Related Topics
• Available solutions

• Solutions and in-form analytics

• Performance Analytics
Major incident overview (dashboard)

Major Incident Overview module provides a dashboard to review major incident information
at a glance.
Users with itil, major_incident_manager or communication_manager role can access the

dashboard.
There are two versions of the PA Dashboard: normal and premium. Incident Management -
Major Incident Management (com.snc.incident.mim) must be activated to view the normal
dashboard. To access the premium version of Major Incident Overview dashboard, you must
activate Performance Analytics – Content Pack for Major Incident Management
(com.snc.pa.incident.mim).
You can navigate to the dashboard in the following ways:
• Incident > Major Incidents > Overview

• Self – Service > Dashboard
Major incident overview
Major Incident Overview module provides information on the following content:
# UI component Description
1 Dashboard controls Provides options to create,
duplicate, or delete a dashboard.
You can copy the dashboard
URL or duplicate the dashboard.
In addition, you can add the
dashboard in your favorite list,

create a tab, or reset filters in
the dashboard.
2 Dashboard overview Takes you to the UI page where
you view the recently accessed
dashboard, dashboards owned
or shared by you, or all the
dashboards in the system. To
create a new dashboard, click
New.
3 Dashboard choice list Provides options to select
between different dashboards in
the system.
4 Add widgets Provides option to add widgets.
You can drag to move or resize
the widget on the dashboard.
5 Sharing Provides option to specify
groups, users, and roles for the
dashboard.
6 Configuration Provides the configuration pane
to select a layout to snap the
widgets against or to modify a
layout as required.
7 Tabs
• Overview
Major Incidents Nearing
Breach: Number of active
major incidents where the
Major incident state is
Accepted and the response
or resolution SLA has
reached 75% of the allotted
time.
Major Incidents Overdue:
Number of active major
incidents where the Major
incident state is Accepted
and the response or
resolution SLA has
breached.
Unassigned Major Incidents:
Number of active major
incidents where Assigned to
is empty.
Open Major Incidents:
Major incidents which are
open and has major incident
state as Accepted.
Major Incidents Opened
Today: Major incident state is
Accepted and the major
incident is created on the
current day.

Note: Major incidents
opened for that
day includes
both active and
inactive
incidents.
Major Incidents Resolved
Today: Major incidents that
are resolved on the current
day and have the state as
Resolved.
Open Major Incidents –
Grouped: You can filter
these incidents based on
Group by and Stacked by.
Open Major Incidents Older
Than 7 Days – Grouped: You
can filter these incidents
based on Group by and
Stacked by.
Major Incidents by Priority
and State
Major Incidents by Priority
and State Older than 7 Days
Major Incidents Opened per
Week
Major Incidents Closed per
Week
Note: You can save the

graphical image in
the .PNG
and .JPEG format
by clicking
that appears
when you hover
on the upper-right
of the image. You
can also refresh
the latest data in
the graph by
clicking .
• Major Incident Candidates
• Active Major Incidents
• Resolved Major Incidents
Major Incident Overview – Premium provides the following additional functions:
• Process KPIs: Provides information on Active Major Incidents, Number of resolved major
incidents, Average resolution time of Major Incidents, and New Major Incidents Vs
Resolved.

• Interactive filters: Helps to filter incidents based on category, priority, assignment group,
and state.
Major incident overview - premium
Related Tasks
Related Concepts
Related Topics
• Create and use dashboards
Incident ticketing integrations

An incident ticketing integration exchanges ticket data between your ServiceNow instance
and a third-party system.
The advantages of an incident ticketing integration include the following items.
• Establishing a ticket number that provides a unique key between systems.

• Synchronizing the systems so that notifications can be triggered.
• Transforming data for more uniform processing.
• Tracking ticket activity for accurate reporting.
The level of data and the direction of the data that is exchanged categorizes the integration
as uni-directional or bi-directional. In a uni-directional integration, a third-party system

creates an incident ticket, passes data to your instance, and receives a ticket ID back as
confirmation. In a bi-directional integration, incident data is exchanged, synchronized, and
updated while data is sent between the systems.
For both integration types, a good practice is to implement a record-based log of the
individual transactions for a given time period. If an outage occurs, a record-based log can
tell you what data was exchanged, how it was transformed, when processing occurred, and
if there were any errors. Record-based logs also allow you to run all the validation and
transformation logic away from the main form, helping performance.
Before implementing your project, develop an integration plan in which all the
implementation aspects and requirements are defined. Developing the integration plan helps
you to review the current data, plan for future requirements, and identify and sequence
project tasks.
Uni-directional incident ticketing integrations

Consider the requirements for an external, third-party system to create tickets. Define the
data that must be sent to create a ticket, and what validation is required.
In this way, a standard web service interface can be created and published. This integration
responds with a ticket number on success, or with a structured error message for validation
failures and processing issues. An advantage of this implementation is that you can publish
once and reuse for multiple applications, provided the additional integrations follow the
integration specifications. A good practice is to create a dedicated account for each
interface. Accounts provide accountability and report user statistics, and use a simple
connectivity Point of Contact (POC).
Integration plan contents
• Firewall requirements
• Protocols to be used
• Required middleware (for example, MS Biztalk)
• Error messages
• Validation rules
Example using basic authentication
This implementation responds to the third-party system with the ticket ID. The Import Set
tables function as a staging area for your data.

Uni-directional ticketing integration using basic authentication
Example using import sets
An implementation variation for the inbound path would be to use the Import Set Tables as
interface tables. In this example, the Incident_Interface Table stores a history of data as it
was received and before the data was transformed. The destination Incident Table could
store a history of how the incident has changed over time and who changed it. The
transform scripts would process the import set and the business rules would run on the
target table.

Uni-directional ticketing integration using import sets
Bi-directional incident ticketing integrations

A bi-directional integration exchanges data between your ServiceNow instance and a third-
party system so that incident information is synchronized between the systems.
This integration is more complex than a uni-directional integration because it has the
following requirements.
• Comprehensive definitions of field mappings.

• Standardization of where transformations take place: inbound, outbound, or both.
• Consideration of the ownership of reference data.
• How updates are performed on an ongoing basis.
Implement error handling. Include all these implementations in the integration plan.
While bi-directional implementations are developed on their own merits, you can develop a
framework in the Now Platform that can be reused, for example, data driven validation rules.
Integration plan contents
• Plan contents for all the aspects needed for a bi-directional integration.
• State models for each organization.
• Business rule definitions for keeping the tickets synchronized.

• Requirements to store history of individual transactions. If this form of audit is a

requirement, consider creating an interface table which is populated prior to creating and
updating the destination table.
• Transformation rules for all data elements.
• Time lines for when reference data is transported to the information system. Include
requirements to perform transformations before sending the data to and from each
system.
• Statement of reference data ownership at all stages.
• Update schema definitions.
Example using import sets and web services
In this implementation, data authentication is done before insertion into the import set.
Transform maps and scripts execute before the data reaches the Incident table. The Incident
table is used to store the history of the incident records. For the outbound data path, the
target table could trigger business rules before the data is queued in the outbound web
service.
Bi-directional ticketing integration using import sets and web services
Example using import sets and the ECC queue
An implementation variation for the inbound path would be to use an import set table (in
our example, the Incident Interface table) to store historical data. Data validation is also
done now, and you can clear exceptions with processing or manual intervention. The
Incident table uses a Third-Party Information table as a reference, and messages are
generated based on business rules.

Implementing this type of integration involves a web-service component for third-party

applications for inbound data. The ECC queue is recommended for outbound data.
Bi-directional ticketing integration using import sets and the ECC queue

Incident Management PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Incident Management PDF

Încărcat de

Drepturi de autor:

Formate disponibile

PDF generated on March 26, 2018

© 2018 ServiceNow. All rights reserved.

March 26, 2018 ©2018 ServiceNow. All rights reserved. 3

Close multiple incidents from the UI action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

March 26, 2018 ©2018 ServiceNow. All rights reserved. 4

The goal of Incident Management is to restore normal service operation as quickly as

ServiceNow Incident Management supports the incident management process in the

• Log incidents in the instance or by sending email.

Explore Set up Administer

Use Develop Integrate

• Create an incident • Developer training • Incident ticketing integrations

Troubleshoot and get help

• Ask or answer questions in the

March 26, 2018 ©2018 ServiceNow. All rights reserved. 5

Incident Management process

March 26, 2018 ©2018 ServiceNow. All rights reserved. 6

Major incident management process involves proposing an incident as a major incident

Incident Management state model

March 26, 2018 ©2018 ServiceNow. All rights reserved. 7

• Awaiting Caller: If you select this option, the Additional

Note: If the caller updates the incident, the

Note: An incident can be placed in the On

Resolved A satisfactory fix is provided for the incident to ensure

March 26, 2018 ©2018 ServiceNow. All rights reserved. 8

Incident management state model flow

Parent-Child state synchronization

March 26, 2018 ©2018 ServiceNow. All rights reserved. 9

Parent State On Hold Reason Child State On Hold Reason (Child)

Closed NA Not closed. NA

Incident priority and data lookup rules

ITIL incident metric order

March 26, 2018 ©2018 ServiceNow. All rights reserved. 10

Data lookup rules

Improvements for the Incident Management process

March 26, 2018 ©2018 ServiceNow. All rights reserved. 11

Incident information plugins

Major incident management process

Major incident management process involves proposing an incident as a major incident

March 26, 2018 ©2018 ServiceNow. All rights reserved. 12

March 26, 2018 ©2018 ServiceNow. All rights reserved. 13

Form configuration and design

• Incident management properties

Templates simplify the process of submitting new records by populating fields

March 26, 2018 ©2018 ServiceNow. All rights reserved. 14

Incident management properties

Properties for incident management

March 26, 2018 ©2018 ServiceNow. All rights reserved. 15

Note: When an incident is reopened, a

March 26, 2018 ©2018 ServiceNow. All rights reserved. 16

Major incident management

Properties for major incident management

Incident categories and subcategories

March 26, 2018 ©2018 ServiceNow. All rights reserved. 17

Configure incident categories or subcategories

Before you begin

Role required: admin

About this task

1. Navigate to Incident > Create New.

Edit Subcategory choices Select the Category to update its subcategory

March 26, 2018 ©2018 ServiceNow. All rights reserved. 18

3. Perform any of the following actions.

Remove existing category Highlight the category to be removed and click

Incident templates and record producers