UTSA SERVICENOW USER GUIDE

Updated by Jessica Abel Wilkinson

18 September 2020
Built on materials provided by Lisa Springer with InSource.
 2
Welcome to the UTSA ServiceNow (SNOW) User Reference Guide.
This guide is a compilation of all UTSA SNOW training materials for your quick and
easy access. Simply click any section to skip to that area of the guide. For questions
or concerns related to ServiceNow, please contact the Tech Café at 210-458-5555
or [email protected].

CONTENTS
Service Portal ......................................................................................................... 6
SNOW Search Engine ......................................................................................... 6
Service Catalog................................................................................................... 9
Submit a Request from the Catalog ................................................................. 12
Acessing Requests from the Portal Homepage................................................. 14
Request Management ......................................................................................... 16
Submitting a Request from the Frameset ........................................................ 16
Catalog Requests, Items, and Tasks.................................................................. 17
Ordering an Item From the Catalog ................................................................. 19
Fulfilling the Request ....................................................................................... 22
Service Catalog Automation ............................................................................. 25
Fulfiller Responsibility ...................................................................................... 25
Standard Service Catalog Notifications ............................................................ 25
Agent Workspace................................................................................................. 26
Navigation........................................................................................................ 27
Change Agent Status ........................................................................................ 29
Visibility ........................................................................................................... 30
Agent Assist ..................................................................................................... 30
 3
Completing an Interaction ............................................................................... 31
Flip an Interaction to an Incident ................................................................. 31
Flip an Interaction to a Request ................................................................... 33
Create a Request from an Incident............................................................... 35
Child Incidents.............................................................................................. 35
Incident Management.......................................................................................... 38
Incident Management Roles ............................................................................ 38
Process Owner ............................................................................................. 38
Incident Manager ......................................................................................... 38
Major Incident Manager .............................................................................. 39
Service Desk Agent ....................................................................................... 39
Tier 2 Support .............................................................................................. 39
Tier 3 Support .............................................................................................. 39
End User....................................................................................................... 39
Incident Management Process ......................................................................... 39
Incident Management States ........................................................................... 40
Incident Notes.................................................................................................. 41
Important: Who Can See What .................................................................... 42
Related Records ........................................................................................... 43
Incident Priority changes ................................................................................. 44
Placing an Incident on Hold.............................................................................. 45
Resolving an Incident ....................................................................................... 45
Task SLAs ......................................................................................................... 47
Add Affected CIs .............................................................................................. 48
Impacted Services /CIs ..................................................................................... 48
Child Incidents ................................................................................................. 49
 4
Impact and Urgency ......................................................................................... 50
Standard Incident Notifications........................................................................ 51
Change Management........................................................................................... 52
Change Management Roles ............................................................................. 52
Change Requester/Change Implementer ..................................................... 52
Process Owner ............................................................................................. 52
Change Manager .......................................................................................... 52
CAB Manager ............................................................................................... 52
Change Advisory Board Members ................................................................ 52
Change Management Process (Summary)........................................................ 53
Change Management States (Summary) .......................................................... 53
Create a Change Request ................................................................................. 53
Types of Changes ......................................................................................... 55
Normal Change Form ................................................................................... 56
Change Request Form Fields ........................................................................ 57
Standard Change Template Library .............................................................. 58
Checking for Conflicts................................................................................... 61
Address a Conflict ........................................................................................ 64
Calculate Risk ............................................................................................... 64
Request Approval from CAB ......................................................................... 66
Delegate Attendance to the CAB Meeting.................................................... 67
Change Request Approval ................................................................................ 68
Put a Change on Hold ................................................................................... 68
Implement the Change................................................................................. 70
Close the Change ......................................................................................... 71
Change Notifications ........................................................................................ 72
 5
CAB Workbench ............................................................................................... 72
Knowledge Management ..................................................................................... 73
Create a Knowledge Article .............................................................................. 74
Attaching a file to a Knowledge Article......................................................... 76
Create Knowledge Articles by Importing Word Files .................................... 77
Create an Article from an Incident or Problem ............................................. 78
Knowledge Management Process .................................................................... 79
Updating Articles/Article Retirement ........................................................... 81
Leaving Article Feedback.................................................................................. 82
Fulfillers ....................................................................................................... 82
End Users ..................................................................................................... 82
Knowledge Article Versioning ...................................................................... 83
Ownership Groups ........................................................................................... 84
Knowledge Blocks ............................................................................................ 86
 6

SERVICE PORTAL
The SNOW Service Portal, accessible here, is used to access the following:

• Knowledge Articles
• Catalog Requests
• Requests submitted by the user
• Organization-wide notifications

Figure 1. SNOW Portal Screenshot

SNOW SEARCH ENGINE

The field under “How Can We Help?” is the SNOW global search engine. You can
use this search engine to search for Knowledge Articles and Catalog Request items.
 7

Figure 2: Search Engine

Search Results will bring up both Knowledge Articles and Catalog Request items.
See below to learn how to search for only one category or the other.

Figure 3: Search Results Example

 8
To search for only Knowledge Articles, go directly to the Knowledge homepage by
clicking Knowledge Base. The Knowledge Base(s) contain articles that provide
users with information such as self-help, troubleshooting, and task resolution. Use
the search engine or navigate by Knowledge Base and Category to search for
Knowledge Articles.

Figure 4: Knowledge Base Search

To search for only Service Catalog Request Items, go directly to the Service
Catalog. The Service Catalog contains all active/available service offerings.

Figure 5: Service Catalog Link

 9
SERVICE CATALOG
A Service Catalog is a customer-facing view of available services and products
offered by departments within an organization. It provides:

• Self-service opportunities for customers within a single interface

• Standardization of approach and delivery of request fulfillment across an
organization
• Management of customer expectations through self-service training of
individual requests
• Behavioral shifts of customers; from relying on emails and phone calls to
accessing catalogs to serve their own needs

Navigation:

Click a UTSA catalog to expand it to view the different categories for that catalog.
Click a category to open the different request options.
 10

Figure 6: Service Catalog Options

 11
Click a request to open the catalog item request form.

Figure 7: Catalog Item Request Form Example

Another way to search for Catalog Items is by clicking Browse all Categories
under the Search field.

Figure 8: Browse all Categories

 12
Browse by Category along the left side of the page until you find the request
form. Click + to expand the category options.

Figure 9: Browse by Category list

SUBMIT A REQUEST FROM THE CATALOG

After locating the request, open a request, fill out the form and click Submit.

Notes:

• Red asterisk fields on the request forms are mandatory.

• Anyone can submit a request on behalf of someone else
• Users can add attachments to a request via the paperclip at the bottom of the
form

If a user cannot find a Request matching their issue, they can create an
incident using the Generic Issue request under “IT Support.”
 13

Figure 10: Service Catalog Request Form Example

Once the request is submitted, a confirmation of the request is provided including

the Request Number.

Figure 11: Sample Request Submission

 14
ACESSING REQUESTS FROM THE PORTAL HOMEPAGE
At any point in time, a user can view all their requests by clicking My Requests.

Figure 12: My Requests

All currently opened requests will be displayed. To access past/ closed requests,
click the caret in the View field to toggle between Open and Closed.

Figure 13: View Requests (Open & Closed)

The requestor/user can open any request at any time to check the status of the
request or communicate with the fulfiller.
 15

Figure 14: Request Status

 16

REQUEST MANAGEMENT
SUBMITTING A REQUEST FROM THE FRAMESET

ITIL Fulfillers have access to both the end-user Service Portal, and the internal
frameset of catalog request items. You may choose to use the frameset method if
you are creating a request for yourself or you are assisting someone else.

Below is an example of a frameset: The Access and Internet Catalog

Figure 15: Request from Frameset

 17
CATALOG REQUESTS, ITEMS, AND TASKS

Catalog Request Process:

Catalog Request Forms are used so Requesters know what they are requesting and
can answer questions about their request, and Fulfillers know what to fulfill.

• Each “order” creates one Request

• Each Request can contain multiple Catalog Items
• Each Catalog Item can spawn one or more fulfillment Tasks

Task (SC Task)

Request Item
(RITM)
Task (SC Task)
Request
Task (SC Task)
Request Item
(RITM)
Task (SC Task)

Figure 16: Request Process

 18
Catalog Item Record and Workflow:
Below is an example of the Catalog Item Record and Workflow. This diagram is
presented only for understanding; ITIL fulfillers will not be creating catalog items
personally.

Figure 17: Catalog Item Record/Workflow Diagram

 19
ORDERING AN ITEM FROM THE CATALOG

Catalog Items are always tied to a workflow. That is the main

value/benefit of Request Management (placing an order from a
Catalog)—the fact that its process is automated.

Once a Request has been submitted, there is no need to follow up on what

to do next.

The first task or approval will show up in the Assignment Group’s “in-box”
(i.e. My Groups Work. A notification is also sent out to the approver(s)
and the Assignment Group members to whom the task is assigned.

When catalog items are created, they are assigned to a catalog and
assigned to a category. A workflow will always be attached to the catalog
item record.

Below are the categories in the Access and Internet Catalog. Inside each category
are the catalog items, also called requests.

Figure 18: Access and Internet

 20
Select the System Access request to open the request form, fill out the form
including all mandatory fields and click Order Now.

Figure 20: Access Request

Figure 19: Access Request Form

 21
Once submitted, the user can view confirmation of the request.

Click the triangle to open the Stages to see the status or progress of the request.

Figure 21: Request Confirmation

Who can access:
The Fulfiller and On-behalf-of can both access the requested item via the Portal >
My Requests.

Figure 22: My Requests View

 22
FULFILLING THE REQUEST
The Service Catalog Task (SCTask) will show up in My Groups Work for those in the
group that the SCTask is automatically assigned to by the workflow.

Figure 23: My Groups Work

Someone from the Assignment Group will open the SCTask, work the task and close
the task.

Figure 24: Work and Close the Task

 23
When the final task of any Requested Item is closed, it will automatically close the
Requested Item (RITM) and the Request.

Figure 25: Request Closed

My Work and My Groups Work

This is where to find and manage your work from the Frameset.

Figure 26: My Work and My Groups Work from the Frameset

 24
From the Agent Workspace, find and manage your work here.

Figure 27: Find and Manage Your Work from Agent Workspace

Note: Use filters and/or reports to add to a Homepage to manage work.

Click the column titles to sort.

Figure 28: Use filters (column titles) to sort

 25
SERVICE CATALOG AUTOMATION
1. A user requests an item from a catalog from the UTSA Portal.
2. A workflow kicks off and the request may start with an approval(s) or a task
(SCTask).
3. The user can go to the portal and check the status of their request at any
time.
4. The request gets approved, each task gets completed, the request is fulfilled
and the SCTasks/RITM/REQ records are all closed.

FULFILLER RESPONSIBILITY
A fulfiller is responsible for managing all their work (via “My Work,” “My Groups
Work,” and/or “Homepage/Dashboard”) and fulfilling all tasks assigned to them.

STANDARD SERVICE CATALOG NOTIFICATIONS

Name Who will receive

Request Opened on Behalf Of Requested for
Request Item Completed Requested for
Catalog Task Assigned to Assignment Group
Group
Catalog Task Assigned to User Assigned to
Manager Approval Manager
 26

AGENT WORKSPACE

Agent Workspace is a graphical user interface that puts multiple tools

on one page. ServiceNow workspaces are designed for tier 1 agents
who solve customer issues.

Workspaces include all the tools that agents need to find, research,
and resolve issues. ServiceNow provides different Agent Workspaces
for different issue types. For example, agents using the IT Service
Management Workspace (ITSM) track and resolve IT issues.

Agents can see all details that are related to an issue in one place – a
single-pane view. An agent can have multiple records open at a time,
all easily accessed on a single page.

Agent Workspace can be opened from the Application Navigator via the Agent
Workspace Home module. When you click the module, it will open as a different
interface in a separate browser tab.

Note: Make it a Favorite and put at the top of the Favorite list for
quick access.

Figure 29: Agent Workspace Home

 27
NAVIGATION

4
1

Figure 30: Workspace Navigation

1. Home (default)
Easily view My Work, and relevant Reports on managing Open Incidents and
SLAs
2. Lists
View lists of Incidents, Requests, Tasks, or create your own under “My Lists.”
From the List View, a fulfiller can access any of their tasks or their group’s
tasks.
3. Inbox
Queue to receive new Incidents or Interactions (Emails)
4. + (New button)
Open a new Interaction Form, then save the record and flip to an Incident
or Request
 28
One of the main benefits of the Agent Workspace interface is that it allows multiple
records to be open at the same time (as tabs).

These records can include: Interactions, Incidents, Problems, Changes, Change

Tasks, Requests, and SC Tasks.

Figure 31: Agent Workspace tabs

Note that the Agent Workspace supports two levels of tabs. In figure 31, the high-
level Interaction form is selected, and a “details” tab is open. If the agent were to
“Create Incident,” another tab would appear next to “details” (still within the
high-level Interaction form).

You can work an Incident in the same manner with all the same
functionality within Agent Workspace as you can working an Incident
within the frameset. Both interfaces offer the same functionality.
 29
CHANGE AGENT STATUS
Change your Status to Available to receive Interactions from the queue.
Interactions are from calls (CTI) and emails sent to [email protected].

Figure 32: Agent Status

 30
VISIBILITY
The icons at the bottom of the form change what is visible in the frame.

1. Form in full
2. Form and Activity
3. Activity in full screen

AGENT ASSIST

Figure 33: Agent Assist

 31
The Agent Assist window can toggle open or closed via the highlighted icon to the
far right of the frame.

Agent Assist can show different types of records based on the text in the Short
Description field.

Select the type of record by clicking the Select a Search Resource icon.

COMPLETING AN INTERACTION
When an Interaction is accepted, the Service Desk Agent will complete the
interaction form and determine if the interaction is an Incident or a Request.

FLIP AN INTERACTION TO AN INCIDENT

Click Create Incident to flip the Interaction to an Incident.

Figure 34: Completing an Interaction

 32

This creates an Incident Record:

Figure 35: New Incident Record

Next Steps: Assign the Incident to yourself, address the Impact and
Urgency, and Save the record.

Figure 36: Incident assignment menu

 33

Note: When the Record is saved, the State changes to In Progress.

Alert: When the Incident is created, the Interaction does NOT

automatically close. The Fulfiller will need to close it.

FLIP AN INTERACTION TO A REQUEST

Click Create Request to flip an Interaction to a Request

Figure 37: Create Request

This will take you to the Catalog, where you will search for and select the Catalog
Item to be requested.
 34

Figure 38: Catalog Item Search

Complete the Catalog Item Request form and click Order Now.

Figure 39: Catalog Item Request Form

 35
CREATE A REQUEST FROM AN INCIDENT
A Request can be created from an Incident by clicking the 3 dots icon and select
Create Request.

Figure 40: Create a Request from an Incident

Select the Catalog Item, fill out the form and save the Request record.

The Incident will remain open after you create the Request and needs to
be processed like any other Incident.

From an Incident, you can Copy Incident, Create a Change Request,

Create a Problem or Propose a Major Incident via the 3-dot icon.

CHILD INCIDENTS
A Child Incident can be created from an Incident when on the Child Incidents
tab (New button).
 36

Figure 41: Other Incident Management Options

When on the Parent Incident, the Child Incident(s) can be found within the Child
Incidents tab.

Figure 42: Child Incidents Tab

 37
When on the Child Incident, the Parent Incident can be found on the Related
Records section.

Figure 43: Related Records

 38

INCIDENT MANAGEMENT

The goal of Incident Management is to restore normal service

operation while minimizing impact to business operations and
maintaining quality.

ServiceNow Incident Management supports the incident management process in

the following ways:

• Log incidents
• 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/caller who reported 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.

INCIDENT MANAGEMENT ROLES

PROCESS OWNER
Maintains the Incident Management process by ensuring the process is
implemented and followed by all stakeholders.

INCIDENT MANAGER
Ensures the incident resolution meets service level targets. Manages
incident escalations, helps coordinate the interaction between incident
support levels and analyzes metrics and improvement opportunities.
 39
MAJOR INCIDENT MANAGER
Responsible for managing tasks and communications within resolution
teams as well as IT and Business stakeholders.

SERVICE DESK AGENT

First line of support for new incidents

TIER 2 SUPPORT
First escalation point from Service Desk and they are SMEs of an IT service

TIER 3 SUPPORT
Next level of escalation. They are technical SMEs/administrators of an IT
service.

END USER
Report incidents when something is not working properly.

INCIDENT MANAGEMENT PROCESS

1. Create an incident
a. Classify the incident
b. Triage the incident
c. Assign the incident record for investigation and diagnosis
2. Investigate the issue (research knowledge articles and known error records
a. Document all findings and steps taken
3. Diagnose the issue
a. Document actions and findings
4. Implement the solution
5. Change the State to Resolved and document the resolution
6. Incident closes automatically after seven days (if end user does not indicate
that the service is not restored)
 40
INCIDENT MANAGEMENT STATES

New – Incident has been logged but not yet triaged.

In Progress – Incident is assigned and being investigated.

On Hold – Incident investigation is paused (due to a problem, a chance, awaiting

customer or external vendor information).

Resolved – Issue is resolved, awaiting confirmation from customer of service

restoration.

Closed – The incident was automatically closed by the system or by an ITIL admin.

Canceled – Triaged incident found to be a duplicate or not actually an incident.

Figure 44: Incident Management States

Note: If the caller updates the incident, the On hold reason field is cleared
and the state of the incident is changed to In Progress. An email
notification is sent to the user in the Assigned to field as well as to the
users in the Watch list.

An incident can be placed in the On hold state one or more times prior to being
closed.
 41
When the status of an Incident is changed to anything but Canceled, Resolved, or
Closed, the Resolve fields are cleared. When an Incident that is in the On Hold
State is updated, the On Hold Reason field is cleared.

If you are not satisfied with the resolution, you can request to reopen the incident
from the resolution notification email or from the incident itself. The state of the
incident is then changed from Resolved to In Progress. If the incident is already
closed, you can open an incident with selected field values from the closed incident
by replying to any email related to the closed incident.

INCIDENT NOTES
Collaborator Notes are internal documentation about how to resolve the Incident
or steps taken to resolve it.

Figure 45: Collaborator Notes

Additional Comments are comments or questions to the customer (Caller) sent as

an email notification. Caller’s email response will be added to the Incident as
Activity.
 42

Figure 46: Additional Comments View

You can toggle between the two fields via the check box.

IMPORTANT: WHO CAN SEE WHAT

Anything you place in the “additional comments” field will be visible

to the caller

Watch List Vs. Collaborators List:

Watch List is for users or groups to receive notifications about the incident when
comments are added.

Collaborators List is for users or groups to receive notifications about the incident
when work notes are added.
 43

Figure 47: Notes and Lists

Users can toggle to reflect one text box or both text boxes for notes/comments by
selecting this icon:

Click the padlock icon to unlock the field to add users or groups to the Watch or
Collaborators list.

Click the icon to add yourself to one or both lists.

RELATED RECORDS
Related Records allow an Incident to be linked to another Incident or a Problem or
a Change Request or will be noted if a Change caused the Incident.

Figure 48: Related Records Tab

 44
INCIDENT PRIORITY CHANGES
When the Priority changes (up or down), a Collaborator Note is required to explain
the change in Priority.

Figure 49: Incident Priority Changes

 45
PLACING AN INCIDENT ON HOLD
An Incident can be put On Hold when the fulfiller is waiting for something out of
their control to resolve the incident. Putting an Incident on hold will pause the
Task SLA. The On Hold also requires information to be provided in the Work
Notes and Additional Comments if Awaiting Customer Response is selected.

Figure 50: Placing an Incident on Hold

RESOLVING AN INCIDENT
To resolve an Incident, click the Resolve button. The system will let you know
there are 2 mandatory fields that need filled in.
 46

Figure 51: Resolving an Incident

Note: An Incident is permanently Closed by the system 7 business days

after it is Resolved if it is not reopened.

Figure 52: Resolution Codes

Knowledge is checked if a knowledge article is created from this incident when it
was closed
Resolution Code is how an incident was resolved
Resolution Notes is communication to the Caller about the resolution of their
incident
Resolved By is the Fulfiller listed in the Assigned To field
Resolved is the date and time when the incident was resolved (stamped by the
system)
 47
When the Knowledge box is checked and when the incident record is Closed, the
system creates a draft knowledge article with some information from the Incident
copied to the knowledge article.

The following fields are copied from the Incident to the Article:

INCIDENT KNOWLEDGE

Short description Short description

Work Notes Text

Number Source

TASK SLAS
Service Level Agreements (SLAs) specify the time within which service must be
provided

Figure 53: Task SLAs

SLAs can be created for any task-type record.

The Response SLA timer stops when the Incident record is assigned to an individual.

The Resolution SLA timer stops when the Incident is put in the Resolved State.
 48
ADD AFFECTED CIS

Add multiple Affected CIs to an Incident to capture all the CIs that are
affected by the same incident.

Note: This is not something UTSA will use initially but is there for use in the future.

Figure 54: Affected CIs

IMPACTED SERVICES /CIS

Identify all Services (CIs) impacted by the Incident.

For now, the system will automatically identify an Impacted Service if applicable.

Figure 55: Impacted Services/CIs

 49
CHILD INCIDENTS

Creating a Child Incident from an Incident copies the details of the Parent
Incident and links the two incidents together. To do this, click the “New”
button.

To link an existing Incident Record (Child Incident) to an Incident (Parent

Incident), click the “Edit” button.

Figure 56: Creating and Editing Child Incidents

The parent and the child incidents are synchronized such that the state of
a child incident changes depending on the state of the parent incident.

 If Parent State is In Progress, Child State is In Progress.

 If Parent State is On Hold Awaiting Change or Problem or Vendor,
Child State is same as Parent.
 If Parent State is On Hold Awaiting Customer Response, Child State is
Not updated.
 If Parent State is Resolved, Child State is Resolved. This should copy
Resolution Notes from Parent to Child.
 If Parent State is Closed, Child incidents must always be closed by
caller or by the system based on auto closure property.
 50
Note: If a parent incident reopens, the child incident state should not change
because the incident is already resolved.

When an incident has a child incident, the following actions take place:

 If an ITIL user reopens the parent incident, then the parent incident as well
as the child incident reopen. Both the parent and the child incident state are
set to In Progress.
 If an ESS user reopens the parent incident, the parent incident state is set
to In Progress but the child incident is not reopened.

IMPACT AND URGENCY

ITIL methodology uses three metrics for determining the order in which incidents
are processed.

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 is determined by Impact and Urgency. Each Priority level (1-Critical, 2-

High, 3-Moderate, 4-Low, 5-Planning) has a Target Resolution and SLA.

By default, the Priority field is read-only

and must be set by selecting the Impact
and Urgency values.
Figure 57: Impact and Urgency States
 51
STANDARD INCIDENT NOTIFICATIONS
 52

CHANGE MANAGEMENT
Change Management application provides a systematic approach to control the
life cycle of all changes, facilitating beneficial changes to be made with minimum
disruption to IT services.

Change Management applies a consistent approach to risk assessment, business

continuity, change impact, resource requirements, and change approval.

Change Management helps to ensure changes are made in a planned and

controlled manner, reduce the number of emergency changes, reduce the
number of incidents caused by changes and reduce the time to process standard
(repeatable) changes.

A Change Request allows you to implement a controlled process for the addition,
modification, or removal of approved and supported configuration items (CIs).

A Change Request records the detailed information about the change, such as the
reason of the change, the priority, the risk, the type of change, and the change
category.

CHANGE MANAGEMENT ROLES

CHANGE REQUESTER/CHANGE IMPLEMENTER – Responsible for the creation and
implementation of changes.
PROCESS OWNER – Maintains the change management process, by ensuring the
process is implemented and followed by all stakeholders.
CHANGE MANAGER – Responsible for day-to-day facilitation of the change
management process. This role is focused on the management and
administration of all changes.
CAB MANAGER – Facilitates the CAB meetings. (Uses the CAB Workbench to help
facilitate the change management process.)
CHANGE ADVISORY BOARD MEMBERS – A group of people who approve changes
by determining if a change has been planned enough to minimize and mitigate
any risk to the service. ITIL Users can join CAB meetings where appropriate.
 53
CHANGE MANAGEMENT PROCESS (SUMMARY)
1. Create a change request
2. Check for conflicts
3. Calculate the risk
4. Request approval from CAB
a. Takes place during the regular (weekly) scheduled CAB meetings
5. Implement the change
a. Make the change
b. Test the change
6. Close the change record

CHANGE MANAGEMENT STATES (SUMMARY)

New – Change is not yet submitted for review
Assess – Peer review is conducted, and technical approvals are received
Authorize – CAB provides final authorization/approval
Scheduled – Change is scheduled and awaiting implementation
Implement – The change work is being conducted
Review – Verification that the change is successful is performed
Closed – Change is closed
Canceled – Change is canceled

Figure 58: State Progression

CREATE A CHANGE REQUEST

Users can create a change request from the change module.
 54

Users can also create a change request from an Incident or Problem. Right-click in
the header bar to open the context menu.

Figure 59: Create a Change Request from an Incident

There are three types of changes: Normal, Standard, and Emergency.

 55
TYPES OF CHANGES
Normal change

A normal change is any service change that is not a standard change or an

emergency change.

Normal change requests follow a prescriptive process which requires two levels
of approval before being implemented, reviewed, and closed.

Normal changes require a full range of assessments and authorizations such as

peer or technical approval, change management, and Change Advisory Board
(CAB) authorization, to ensure completeness, accuracy, and the least possible
disruption to service.

Normal changes are most often scheduled outside of defined change blackout
windows or during defined maintenance windows.

Normal changes are used to implement beneficial change for any change to a
service that is not a standard or emergency change.

Standard Change:

A standard change is a pre-authorized change that is low risk, relatively common

and follows a specified procedure or work instruction.

A standard change is one that is frequently implemented, has repeatable

implementation steps, and has a proven history of success.

Because standard changes are pre-approved, they follow a streamlined process in

which group level or peer approval and CAB authorization steps are not required.

Approved standard change requests can be predefined in a catalog of templates

to make accessing and requesting a standard change more efficient. This ability
also enables the Change Management team to control the changes that are
authorized as standard.

Emergency Change:
 56
An emergency change is a change that must be implemented as soon as possible;
for example, to resolve a major incident or implement a security patch.

An emergency change is of such a high priority that it bypasses group and peer
review and approval and goes straight to the authorization state for approval by
the CAB approval group.

Emergency changes cover the following types of emergencies:

 Fix or fail of retroactive situations where the impact to service has already
been experienced.
 Fail or fail situations where the impact to service is imminent if action is not
taken.

Emergency changes do not follow the complete lifecycle of a normal change due
to the speed with which they must be authorized. Therefore, they progress
directly to the authorize state for approval from the CAB Approval group.

NORMAL CHANGE FORM

Figure 60: Normal Change Form

 57

CHANGE REQUEST FORM FIELDS

Form Fields Content
Number Displays the change request number
Requested By The user who requested the change.
This field is available in the change
requests list view, so that you can see
who requested a particular change
Category The category of the change (e.g.,
hardware, network, software)
Configuration Item Configuration item (CI) that the change
applies to
Priority How quickly the service desk should
address the task
Risk The risk level for the change (i.e., high,
moderate, low). You can also use Risk
Calculation and Risk Assessment to
drive the risk value of the change
 58
Impact The effect that the task has on
business
Type The type of change request. This field
is read-only
State The state of the change request. The
default state is “new”
Conflict Status Displays whether there is a conflict for
this change, or the conflict is not run
Conflict Last Run Displays the date and the time when
the conflict was last run
Assignment Group The group that the change is assigned
to
Assigned to The user that the change is assigned
to. If an assignment rule applies, the
change is automatically assigned to the
appropriate user or group
Short Description A summary of the change
Description A detailed description of the change

STANDARD CHANGE TEMPLATE LIBRARY

Figure 61: Standard Change Template Library

 59
Use Template Management to create new standard change templates.

To create a standard change, fill out the change form and click Submit.
Note that many fields are already filled out.

To create a normal change, fill out the relevant change form and click Submit.

Figure 62: Template Management

 60

Figure 63: Normal Change Form

Then, fill out the Planning and Schedule tabs.

Figure 64: Planning Tab

 61

Figure 65: Schedule Tab

CHECKING FOR CONFLICTS
Next, check for Conflicts.

Figure 66: Check Conflicts Button

To run conflict detection, the Configuration Item and Planned start and End dates
on the Schedule tab must be completed.

To check conflicts, click the Check Conflicts button on the Conflicts tab.

The system will check for conflicts; any conflicts detected will appear on the
Conflicts tab.

Types of Conflicts:

• CI Already Scheduled
• Parent CI Already Scheduled
• Child CI Already Scheduled
 62
• Not in Maintenance Window
• Parent Not in Maintenance Window
• Child Not in Maintenance Window
• Blackout

If conflicts are identified, the Conflict status field is updated to reflect a conflict and
an error message directs you to the Conflict form section of the Change request
form to review conflicts.

When you create a change request and provide a configuration item, planned start
date, and planned end date or update any of those values, conflict detection is
executed automatically.

To manually execute conflict detection, click the Check conflicts button in the
Conflicts form section.

Click Conflict Calendar to open the Conflict Calendar and click Scheduling Assistant
to open the Change Schedule.

Figure 67: Conflicts Calendar

 63

1. View Form - Returns to the Change Request form.

2. Calendar - Opens the calendar dialog to choose a date.
3. Current Day or Month - Click Today to view the current day or month.
4. Navigating dates - Click the arrow buttons to navigate to the previous or
next day.
5. Scheduling Assistant - Displays the list of available time slots to choose to
resolve conflicts.
6. Day or Month view - Change the calendar view to a day view or month
view.
7. Keyboard shortcuts - Provides keyboard shortcuts for quick navigation.
8. Options - Displays the configuration filters that allows you to select and
display the Assigned to, Assignment group, Configuration item, or Show all
under the Related Changes section that has the same value of the option
selected for the current change.
9. Change request block - Click to view the details of the change request.
10. Related Changes - Helps you to detect other scheduled changes that
potentially conflict with the change based on a schedule or assignment. For
example, if the same person is assigned to two or more changes at the
same date and time, you can visually see this and update one of the
scheduled changes, as appropriate.
 64
ADDRESS A CONFLICT
Click Scheduling Assistant link to see the Change Schedule.

Change the Planned Start Date and Planned End Date to fall within the Change
Schedule.

Figure 68: Conflict Check Completed

CALCULATE RISK
Click Risk Assessment under Related Links to open the risk assessment/survey.
Answer the assessment questions and click Submit.
 65

Figure 69: Risk Assessment

Based on the survey responses, the system will calculate the Risk and
automatically change the risk field on the change record. (Note
messages at top of record when assessment is
submitted.)

The responses to the risk survey can be changed after the initial submission.

Users can click Calculate Risk at any point to have the system recalculate the risk.
It will calculate the risk and impact of the change based on the related risk
assessment and/or defined risk conditions.
 66
Users can click Calculate Risk under Related Links to calculate the risk of the change
without the risk assessment being filled out. (Note: if the assessment has been
submitted, the system will also take the responses into account in addition to any
identified Risk Conditions when calculating the risk.)

Figure 70: Calculate risk without filling out Risk Assessment

REQUEST APPROVAL FROM CAB

Click Request Approval to send the change to the CAB.
 67

Figure 71: Request Approval Button

Note: Many fields are mandatory before you can click Request Approval.

DELEGATE ATTENDANCE TO THE CAB MEETING

If the person who creates the Change Request cannot make the CAB meeting, they
can delegate someone else to attend in their absence via the CAB Delegate field on
the Schedule tab. The attendee attends the meeting to describe the change.

CAB can place any comments or recommendations that arise during the CAB
meeting related to the change in the CAB Recommendation field.

Figure 72: CAB delegate and recommendation fields

 68
CHANGE REQUEST APPROVAL
1. First approval in the change workflow is requested from 1 person in the
Assignment Group.
2. The second approval in the workflow is requested from 1 or more CAB
members.

When a Normal Change is fully approved, the state moves to Scheduled.

Figure 73: Normal Change Request Approved and Scheduled

PUT A CHANGE ON HOLD

A Change can be put on hold by checking the On Hold box and adding an
explanation for the reason.
 69
You can put a change request On Hold when it is not in the New, Canceled,
or Closed state.

Figure 74: How to put a change request on hold

Important Details:

Change tasks inherit some state conditions from the parent change request
they are related to. When a change request is placed on hold, these
conditions are applied to it:

• If the change is waiting for approval, the pending approvals are

marked No Longer Required. When the change request is no
longer On Hold, the pending approvals are reinstated and
are Awaiting approval.
• The change can progress only to the Canceled state while it is On
Hold.
 70
• If a change request is canceled while it is On Hold, then its On
Hold flag is set to false so the change cannot be canceled and still
be On Hold.
• If the change request is set to On Hold, the value of the On Hold field
for all the active change tasks for that change request is set to and
the On Hold reason is copied from the change request to the change
tasks.
• If you clear the On Hold check box in a change request, the On
Hold field for all the active change tasks for that change request is set
to false and the On Hold reason is cleared from the change tasks.
• If the change request is canceled, all the active change tasks related
to that change request are also canceled.
• A change request can only be closed when all the active change tasks
related to that change request are closed or canceled otherwise a
pop-up appears notifying that there are open change tasks that
require to be closed.
• If there are existing change tasks that are manually placed on hold,
those change tasks do not get overwritten when the change request
is placed to the On Hold state. Similarly, when the change request is
taken off the hold state, the change tasks that were placed on hold
manually stays in the On Hold state.

IMPLEMENT THE CHANGE

When ready to implement the change, click Implement. This puts the change
request into action. The workflow then creates two change tasks: Implement and
Post-Implement testing. Review the change tasks and assign them to a user or
group, as appropriate.
 71

Figure 75: Implement a change

Figure 76: Change Tasks (Implement & Post-Implementation testing)

Click Review after reviewing all change request details. This moves the request to
the Review State. Note: When the change request is moved to the review state, all
open change tasks (if any) are set to canceled.

CLOSE THE CHANGE

When the change is complete, fill in the two mandatory fields (close code and close
notes) and click the close button.

Figure 77: Close button

 72

Figure 78: Closure Information

CHANGE NOTIFICATIONS

CAB WORKBENCH
The Change Advisory Board (CAB) workbench enables a CAB manager to schedule,
plan, and manage CAB meetings as well as to automate manual tasks.

CAB meetings are typically intended to review and authorize change requests and
review recently implemented changes. A standard agenda with the relevant change
request details enables the CAB members to conduct risk and impact analysis prior
to the CAB meeting.
 73

KNOWLEDGE MANAGEMENT

The ServiceNow® Knowledge Management (KM) application enables the sharing of

information in knowledge bases. These knowledge bases contain articles that
provide users with information such as self-help, troubleshooting, and task
resolution.

Knowledge bases are often organized by company departments (IT, HR, Facilities,
Marketing) and can also be organized by internal users of a department and
external users.

Knowledge Management can increase efficiency and improve customer service by

allowing employees to get the information they need when they need it (self-
service).

Knowledge Management supports processes for creating, categorizing, reviewing,

and approving articles. Users can search and browse articles as well as provide
feedback.

To support multiple groups, knowledge bases can be assigned to individual

managers. Separate workflows can be used for publishing and retiring articles, and
separate access controls can be used to control reading and contributing.

Note: End users access the knowledge base from the portal, while ITIL
Fulfillers access the knowledge base from the Frameset.

Figure 79: Knowledge Base Homepage

 74
CREATE A KNOWLEDGE ARTICLE
A Fulfiller can create a Knowledge article via the Create New module within the
Knowledge application. All users with at least one ServiceNow role can create and
edit knowledge articles.

Figure 80: Create New Knowledge Article

Before creating a new article, make sure there is not already an article
on the same topic by clicking the “Search for Duplicates” button.

Figure 81: Select the Attachment Link box to download the

attachment upon opening the article

The Short Description becomes the title of the Knowledge Article.

 75
Once you click “submit,” a draft of the article is created and is in the Unpublished
module.

Figure 82: an unpublished article

Next, open the draft article and click Publish to move it to the next stage:
approval state. Note: clicking “publish” does not publish the article to the
knowledge base— only to the approval state.

Figure 83: Publishing an article to the Approval State

 76
Once the article is approved, it can be accessed in the Publish module and is
available for end users to search/access the article from the Portal page (provided
they meet the User Criteria established for the Knowledge Base). Users can only
search for and view published articles.

User Criteria is the method by which fulfillers can establish who can and
cannot access a knowledge base.

User Criteria can be established by users, groups, roles, companies, locations,

and/or departments.

User criteria can only be set by knowledge managers or administrators.

ATTACHING A FILE TO A KNOWLEDGE ARTICLE

To attach a file to a knowledge article, use the paperclip icon and click Submit.

Figure 84: Attaching files to knowledge articles

If you want to open the article without automatically opening the attachment, click
the Display Attachment box.
 77

Figure 85: Display but not automatically download an attachment

CREATE KNOWLEDGE ARTICLES BY IMPORTING WORD FILES

Word documents can be imported to the body of a knowledge article. To upload a
Word document, click the import articles module, fill out the form, add the file(s)
and click import.

Figure 86: Importing a Word Document to the body of a Knowledge Article

 78

The imported Word file becomes a draft knowledge article that follows the same
knowledge article workflow for the specified Knowledge Base.

CREATE AN ARTICLE FROM AN INCIDENT OR PROBLEM

A Fulfiller can create a knowledge article when resolving an Incident or Problem so
that next time the issue comes up, the resolution is defined and available.

The Incident Short Description becomes the title of the article.

 79
Figure 88: Click the Knowledge check box to create a draft knowledge article

The additional comments from the Incident form go to the body of the article.

For detailed information on creating knowledge from an incident, refer

to https://docs.servicenow.com/bundle/paris-it-service-
management/page/product/itsm-workspace/task/create-knowledge-article-
workflow.html

The newly created draft article can be accessed from the Unpublished module of
the Knowledge application.

The article can be reviewed, edited and Published for Approval, then published to
be made available to the users who match the User Criteria of the Knowledge Base.

Fulfillers can use a knowledge article to create an incident when viewing that
knowledge article from the frameset.

Figure 89: Create an incident from an article in the frameset

KNOWLEDGE MANAGEMENT PROCESS

1. Create a knowledge article and click Submit to move it to the next stage in
the knowledge workflow.
2. Once submitted, the article can be found in the unpublished module.
 80

Figure 90: unpublished module

3. Open the article and click Publish to move the article from the draft
workflow state to the review workflow state. The publish button does not
publish the article for users to view until it has been approved.
4. The Knowledge Base Owner/Manager will find the approval request in their
My Approvals module within the Service Desk application.

Figure 91: My approvals module

5. The Knowledge Base Owner/Manager will open the Approval Request,

review, and click the respective button to Approve/Reject the article.
6. When the article is approved by the Knowledge Owner/Manager the article
workflow state will change to published.

Figure 92:Published workflow state

 81
UPDATING ARTICLES/ARTICLE RETIREMENT
When applicable, the author of the article will click Retire to retire the article. The
Knowledge Owner/Manager will need to approve the retirement of the article.

Figure 93:Retiring an article

All retired articles are located in the Retired module of the Knowledge application.

Figure 94: Retired module

The purpose of the Valid To field is to set a date for reviewing the article to
determine if it is still accurate and current.

If the article is still current but needs to be updated (edited), then the article will
go through the knowledge workflow again (require approval if that is the workflow
established at the Knowledge Base level). If the article is no longer current, the
article will be Retired.

Best practice is for the Knowledge Owner and/or Manager to create a dashboard
of articles that are expected to retire in the near future (30 or 45 days out) and let
 82
the author know to review, establish a new Valid To date, republish the article or
retire the article.

LEAVING ARTICLE FEEDBACK

FULFILLERS
Fulfillers can:

• Flag an article
• Rate the article (1-5)
• Communicate if an article was helpful
• Leave a comment

Flagging an article will bring it to the attention of the author or knowledge

manager, indicating that something may need to be verified or corrected. A
separate window will open to comment on what should be changed.

END USERS
End users can:

• Rate the article (1-5)

• Communicate if an article was helpful
• Leave a comment

Users can view and/or post comments to articles and respond to others’
comments.

Article feedback can be accessed via frameset by admins, knowledge managers,

knowledge admins, and article authors.

Article feedback is located on the knowledge feedback related link tab of the article
form.
 83

Figure 95: Knowledge Feedback Tab view

KNOWLEDGE ARTICLE VERSIONING

If an article needs to be updated, the author can check out the article, make the
changes, publish the article, wait for approval and the article will be Re-Published
with an updated version number.

Version numbers are located next to the article number.

To make an outdated article current, go to Knowledge>Articles> All and open the

Outdated article.
 84

Figure 96: Make past article version current

Click the make this current button and follow the normal process to publish an
article.

OWNERSHIP GROUPS
Ownership groups can be configured and associated with knowledge articles to
maintain article quality, manage approvals, and for timely resolution of feedback.

Can assign an ownership group to a knowledge article and shift the ownership of
an article from a single person to a group. An ownership group consists of a group
of members and a manager who are responsible for knowledge articles.

Users with knowledge_domain_expert or knowledge_admin roles can create

ownership groups. Users with knowledge_group_manager or knowledge_admin
can edit ownership groups.

When an Ownership Group is created, a manager and members are

assigned/added.

When a knowledge article is assigned to an ownership group:

• Only ownership group members have contribute access to the article even
if they do not have contribute access to the knowledge base of the article.
 85
They can edit, approve, publish, and retire the knowledge article with
which they are associated.

• Users who are not a member of the ownership group cannot contribute to
the article even if they have contribute access to the knowledge base of the
article.

When creating or editing a knowledge article, the Ownership Group field may
need to be added to the Knowledge form.

Ownership responsibilities include:

• approving knowledge articles

• performing AQI checks to ensuring article quality
• managing feedback tasks for knowledge articles.

To create an ownership group:

Navigate to Knowledge > Ownership Groups > Manage Groups

Figure 97: Create an ownership group

When you click “order now,” a request is created. When it is approved, the group
members are given their needed/respective roles.
 86

KNOWLEDGE BLOCKS
Knowledge blocks are reusable pieces of content secured by user criteria that you
can add to knowledge articles in a knowledge base. The user criteria controls
which users can read or not read the block content in an article or search, enabling
users to more easily view content that is relevant to them.

To use knowledge blocks, a knowledge administrator or manager must enable the

knowledge blocks feature for each knowledge base in which the blocks will be
used.

Knowledge contributors can create knowledge blocks and insert them into articles
in a knowledge base.

Figure 98: Enable knowledge blocks

Enable the knowledge blocks feature for each knowledge base where you plan to
use the blocks. Once enabled, you can create knowledge blocks to add to
knowledge articles within a knowledge base.

Navigate to Knowledge > Administration > Knowledge Bases

 87
Note: If the Enable blocks check box is not visible, you can add the field to the
form by right-clicking the form header and navigating to Configure > Form
Layout.

Note: If you decide to later disable the knowledge blocks feature, all knowledge
blocks within the knowledge base must be deleted before you can clear the box.

Figure 99: Create new block

Create or modify a knowledge block to define a reusable piece of content that can
be inserted into knowledge articles in a knowledge base.

Navigate to Knowledge > Knowledge Blocks > Create New Block.

The knowledge block is secured by user criteria, which controls what users, groups,
roles, companies, locations, or departments can read or not read the content in an
article or search, enabling users to more easily view content that is relevant to
them.

Assess the quality of knowledge articles with the article quality index (AQI). The AQI
helps maintain consistent quality of knowledge articles attached to a knowledge
base where articles are written by various authors.
 88
AQI Process
1. Create an AQI checklist.
2. Assign the AQI checklist to a knowledge base.
3. Perform an AQI review to evaluate the quality of the article.
4. Monitor pending and completed reviews.

Figure 100: Create an AQI checklist

Create a checklist of questions that reviewers can use to evaluate the quality of
knowledge articles.
 89
Navigate to Knowledge > Article Quality Index > AQI checklists, click New, and fill
out the name of the checklist and description. Then, click Submit.

Once the AQI Checklist record is created, the Checklist Questions show up as a
Related List. Click New to create a question.

Figure 101: AQI Checklist Questions