huit functional tech spec...

Functional and Technical Specification

Incident Management

Revision: 11.0Revision Date: 03/08/2013Release Date: 2/28/2013

Author: John Worthington

Functional/Technical Specification

HUIT_Functional_TechSpec_v11a.docx March 8, 2013 Version 11.0


Incident Management



Document Control

Revision Description Author Approved By Date

1.0 Pre‐Draft Template J. Worthington R.Lo 1/25/13

1.1 – Initial Draft J.Worthington

6.0 Final Draft (2.0 – 6.0 core team edits) need to

add authentication, bulk data load approach and

parameters.

J.Worthington 2/15/13

7.0 Additional core team edits 2/20/13

8.0 Additional core team edits 2/22/13

9.0 Moved ISSUES to body of document J.Worthington R.Lo 2/22/13

10.0 Resolved issues. J.Worthington 2/22/13

11.0 Final edit’ spec frozen J.Worthington 3/8/13


Incident Management



Table of Contents

Introduction............................................................................................................................. 4

Functional Design Scope .......................................................................................................... 4

Incident Management Application ................................................................................................... 4

Screen Design & Field Specifications ........................................................................................ 4

Screen Design ................................................................................................................................... 4

Status Diagram ...................................................................................................................... 14

Notifications .......................................................................................................................... 15

Confirmation email (from inbound email / portal) .......................................................................... 15

Assigned to a group email .............................................................................................................. 16

Assigned to an individual email ...................................................................................................... 17

Resolution email ............................................................................................................................ 18

Survey Questions ................................................................................................................... 20

Reports .................................................................................................................................. 21

Incident Management .................................................................................................................... 21

Generic Requests ........................................................................................................................... 27

Integration Requirements ...................................................................................................... 28

Event Driven Integrations ............................................................................................................... 28

Batch‐Loaded Integrations ............................................................................................................. 29

Authentication ............................................................................................................................... 30

Technical Design Requirements ............................................................................................. 30

Workflow Configuration Requirements .......................................................................................... 30

Employee Self‐Service (for Incidents & Generic Requests) .............................................................. 32

Appendix ............................................................................................................................... 36

Approval ................................................................................................................................ 36


Incident Management



Introduction This Functional and Technical Specification has been prepared for ServiceNow to facilitate the design

and implementation of the ServiceNow ITSM application suite for HUIT.

Functional Design Scope The initial design of the HUIT Incident Management process will include any break/fix issues associated

with customers of teams that are already using HUIT Remedy, including some departmental teams such

as Campus Services, Library Services and the Divinity School.

Additionally, the initial implementation of Incident Management must incorporate a ‘generic’ request

process, which will incrementally add specific standard service request models over time after the June

go‐live date..

Both Incidents and Requests will be coming through phone, e‐mail, a self‐service portal and walk‐ins to

the Service Desk.

It is important to understand that the initial release of Incident Management is intended to establish a

standard Incident Management process by June 2013, and that future improvement cycles will update

capabilities (other process and/or application integration) over time. The initial deployment (June

2013) of ServiceNow is Phase 1 and intended to begin to establish a standard Incident Management

process across HUIT. Some features of the application (such as task records for Incident Management)

will be provided after a standard process has been achieved.

Incident Management Application HUIT’s Incident Management process is described in the Incident Management Process Description. The

HUIT application for Incident Management is Service‐Now. Information about the ServiceNow

application can be found on the ServiceNow Wiki site:

http://wiki.servicenow.com/index.php?title=Main_Page

Screen Design & Field Specifications

Screen Design

Overview (Home) Pages The following home pages were identified with the content desired for each:

Technical Resources & Analysts (Tier 1 & 2) (including the Service Desk) o My Work


Incident Management



o Stuff I need to pick up (Unassigned to my group) Management

o Tickets by Group o Breached tickets by group o Major Incidents / High Priority by group

Service Owner

o Number of Incidents by service o Number of incidents by priority by service

The Service Owner may also be a Manager; they would need to choose which Home Page they would like to use.

Assignment Group Manager

o What each person is doing o What is in my queue o My groups oldest tickets o Breached service level targets

Figure 1 illustrates the HUIT style guideline. Area 1 is for navigation (levels 2‐4), area 2 is for the main content and area 3 is for information snippets such as news, ticket summary counts, etc.

Welcome:�[ROLE�NAME]�

Content�Block� Content�Block�

Content�Block�

Content�Block�

Content�Block�

Content�Block�

Naviga on�

Header�

Footer�

Tickets by Group

Breached Tickets by Group

Major Incidents/High Priority

by Group


Incident Management



Figure 1 –Style Guideline

The HUIT branding guidelines are located here:

http://isites.harvard.edu/fs/docs/icb.topic937886.files///HUIT%20Guidelines%207‐25‐11.pdf


Content�Block� Content�Block�

Content�Block�

Content�Block�

Content�Block�

Content�Block�

Naviga on�

Header�

Footer�

Area 1

Area 2Area 3


Incident Management



Service desk rep (First Line) Figure 2 illustrates the home page for 1st Tier support, including the Service Desk. NOTE: Individuals may

set their home page to a primary Incident or Request screen as well (i.e., Create New Incident, Assigned

to Me, etc.)

Figure 2 ‐ 1st Tier & Service Desk Home Page

Area 1 ‐ Navigation Content Block Field Name Description

Incident Management Dropdown to navigate to Incident screens

Create New Assigned to me My Groups Work Open


Self‐Service��

Service�Desk�

Incident�

Problem�

BSM�Map�

Change�

Config

u

ra on�

Service�Catalog�

Reports�

Social�IT�

Open�Items�by�Escala on�Graph�

My�Groups�Work�

My�Work� News�

ITIL�Summary�Counts��

• Cri cal�Items�• Overdue�Items�

• Items�Opened�>�1�Week�

Contact

Reports


Incident Management



Open – Unassigned Resolved Closed All

My Work Reports Dropdown to navigate to Reports screens

View/Run Scheduled Reports ITIL KPI Reports Summary Sets

Table 1 ‐ 1st Tier & Service Desk Home Page Fields

Hidden: Problem, Change, Configuration, Service Catalog, BSM Map, Social IT

Area 2 (Main Content) The main block will contain two content blocks as described below.

My Work / My Groups Work – A list block with the fields described below; generates a list of links

dynamically by querying a table that provides all the work associated with the individual/group. When

the user clicks a link, the associated content renders in a detail page based on its content type.

Each line in the list has a checkbox for selecting multiple rows, and an information button that will pop‐

up the Incident content box for the line item.

Field Name Description Incident Number Auto‐generated number. Can mask to ‘Number’Short Description Text Contact Name of person initiating the Incident; masked as ‘Caller’

Table 2 – 1st Tier 7 Service Desk Home Page List Block Data Fields

Area 3 – Information Snippets The snippets block will contain three content blocks as described below.

Open Items by Escalation Graph ‐ (Content derived from the system)

News – This displays live feeds and news about outages, etc. (Content derived from the system)

ITIL Summary Counts – This provides real‐time counters for: Critical Items (Open items that have a

priority of High and/or Major Incident), Overdue Items (Open items that have attained an overdue

escalation value) and Items opened for greater than 10 business days (Items that have stayed open for

longer than a 10 business days).


Incident Management



Incident Screen (main content area) The Incident screen contains the following content blocks:

Incident

Notes

Work notes

Closure information

Related records

Submit/Resolve

Figure 6‐ illustrates the main content blocks and related fields for the Incident block.

Figure 3 ‐ Incident Content Block

Incident Block ‐ FIELDS Required

Field Name Description Type Open Close

Incident Number Auto‐generated number. Default mask is

‘Number’ String Y Y

Short Description Text Text Y Y

Incident Management Dropdown to navigate to Incident screens Reference Y Y

Contact Includes all the user contact information

(including HUID). Auto‐filled to the extent

possible. Also store alternate contact info.

Renamed from ‘Caller’.

Reference Y Y

Configuration Item Optional field. “Light weight” way to handle

HUIT Remedy Product fields

Reference N N

Incident / Request Drop down to select type of ticket (default is

Incident) If Request, transfer to Request

screen.

Reference Y Y

Service Category Separate line on the Incident form. Re‐named

from ‘Category’.

Reference Y Y

Additional Fields: Incident/Request Incidents by Same Contact Symptom/Operation Incidents by Same Category Related Incidents


Incident Management



Service Drop down / search, options depend on the

service category selected. Separate line on the

Incident form. Re‐named from ‘sub‐category’.

Reference Y Y

Symptom / Operation Drop down, options depend on whether it is

an incident / request. Separate line on the

Incident form. If there is a default escalation

group associated with the Service or Symptom,

it should auto‐populate the filed on the form.

Reference Y Y

Impact Drop down, default to 4‐ Individual Reference Y Y

Urgency Drop down, default to 2 – Work degraded Reference Y Y

Priority (Calculated from impact and urgency – see the

Priority Matrix in Process Description); if VIP,

raise Priority by a factor of 1.

Reference Y Y

Opened by Auto‐filled based on login profile of person

entering the ticket

Reference Y Y

Contact Type Drop‐down choices:

Phone Email Portal Direct Entry (walk‐in)

Y Y

State Drop‐down choices:

New – just received, not touched Unassigned – has group, by no individual Assigned – has a group, has an individual On hold – (see policy) Resolved – only the person assigned can resolve the Incident Closed – verified OR automatically closes after 5 days Cancelled – from any status

Reference Y Y

Assignment Group If not resolved by first line group, the default is

based on category / service / symptom

Y Y

Assigned To Name of individual that the Incident is

assigned to

Y Y

Related Incidents Related incidents are not kept in sync. Should

be able to select closed incidents.

N N

Incidents by same

contact

List field of Incidents by same contact N N

Incidents by same

category

List field of Incidents by same category N N

Table 3 –Incident Block Fields

Screen Icons and Controls:


Incident Management



Upper –left (green arrow) button named ‘Incident’

o A drop down field with the following choices; (Problem, Request, Change; these fields

will be hidden)

Upper‐Left Incident Control ‐ Drop Down Select Lists

Incident

Save Create Change Create Problem Create Request Copy URL

Incident/Export

PDF (portrait) PDF (Landscape)

Incident/Assign

Label

New

Comments

Opens New Label pop‐up

window, ‘Please enter name for

the new label’

Table 4 Fields ‐ Incident Control Drop Down Fields

Figure 7 illustrates the Notes content block

Figure 4 ‐ Notes content block

Notes Block ‐ FIELDS Required


Customer Watch List Multiple people that are automatically

informed of activity on the ticket; default field

mask is ‘Watch List’

Icon N N

IT Watch List Multiple people that are automatically

informed of work notes associated with the

ticket; default field mask is ‘Work notes list’

Icon N N

Comments for Customer Multi‐line text box. An in progress message is

entered into this field. Emails go to contact

and individuals on the customer watch list.

Default field mask is ‘Additional comments

Text N N


Incident Management



(Customer visible)’

Table 5 ‐ Notes Block Fields

Figure 8 illustrates the Work notes Block

Figure 5 ‐ Work notes

Work notes Block ‐ FIELDS Required


Work Notes Multi‐line text box. Emails go to IT watch list. Text N N

Sensitive Notes Removed Text N N

First Line knowledge

sharing opportunity

Checkbox Checkbox N N

First Line opportunity

notes

Multi‐line text Text N N

Table 6 ‐ Work notes Block Fields

Figure 9 illustrates the Closure information Block

Figure 6 ‐ Closure information

Closure information Block ‐ FIELDS Required


Knowledge FIELD WILL BE HIDDEN Checkbox N N

Closed by Auto‐fill based on login of person closing the

ticket.

Reference N Y

Close Code FIELD WILL BE HIDDEN Reference N Y

Close notes Text N N

Closed Auto‐fill based on closure or if status has been Date N Y

ADD: Sensitive Notes Field


Incident Management



‘Resolved’ for more than 5 business days

Table 7 ‐ Closure information Block Fields

Figure 10 illustrates the Related Records Block (hidden)

Figure 7 – Related Records (Hidden)

Field Name Description

Problem Hidden Change Request Hidden Caused by Change Hidden Table 8 ‐ Related Records Block (hidden)

Figure 11 illustrate the Submit / Resolve Incident Block

Figure 8 ‐ Submit / Resolve Incident

Submit/Resolve Incident Block ‐ FIELDS Required


Submit Button to record data on form Y Y

Resolve Incident Button required to change state to

‘Resolved’

N N

Table 9 ‐ Submit/Resolve Incident Block Fields

Other Functionality:

We would to see one of the following functionalities:

1. A “Save” button that updates the current form but keeps the user on the current form

view. The default “Update” button would be hidden or removed.

2. If it does not break functionality in other forms, the “Update” button could be renamed

“Save & Return” to save the update to the form and return the user to their default

view, and a “Save” button added to save the update to the form but keep the user on

the current form.


Incident Management



Status Diagram

Figure 9 ‐ Status Diagram

On Hold Statuses (SLO clock is stopped)

Open Statuses

New

Unassigned

Assigned

On-Hold Waiting for User

On-Hold Waiting for Approval

On-Hold Waiting for Vendor

Resolved

Closed Cancelled

Status automatically set to “ Unassigned” when the Assignment Group is changed. Note: for phone or walk-ins, the status remains at “ New” when the Assignment Group is completed for the first time.

Status automatically set to “ Closed” after 24 business hours.

Status automatically set to “ Unassigned”

and “ Assigned To” field is blanked when

the user clicks the link in the Resolved

Notification email indicating Incident is

not resolved. Status can only be changed to “ Resolved” if all tasks are “ Closed” .

Status automatically set to “ Assigned” when the “ Assignment To” field is changed.

Status automatically set to “ Assigned” when

user updates replies in Portal or via Email.

After 5 Business Days


Incident Management



Notifications Triggers for Customer e‐mails:

Open ticket

Entry in customer notes field (need example)

Resolution

The system will have the capability to open/close a ticket without sending a customer e‐

mail/notification.

Confirmation email (from inbound email / portal) Your support request has been received and Case ID [Incident Number], has been created

Dear [Requestor Name],

Thank you for contacting Harvard University Information Technology. Your request for assistance has

been received and the Case ID is listed below in the event you need to make reference to it in future

communication.

Case ID: [Incident Number] (Incident Number will be a hyperlink to the Incident)

Summary: [Short Description]

Please retain your Case ID for reference purposes.

If you have a question about your support request, or would like to provide more information, please

contact HUIT Support Services at 617‐495‐7777. For an Urgent issue, call the Service Desk when

resources are available to grant access and/or assist in diagnosis and troubleshooting.

Sincerely,

Harvard University Information Technology HUIT Support Services Central Administration Support (617) 495‐8411 FAS Support (617) 495‐9000 HUIT Support (617) 495‐7777 [email protected] http://huit.harvard.edu


Incident Management



Figure 10 – Current Confirmation email

Assigned to a group email

From: HUIT Support Center <[email protected]>

Subject: Incident [Incident Number] (Incident Number will be a hyperlink to the Incident) has been

assigned to your group '[Assignment Group]' Priority: [Priority] Summary: [Short Description]

Date: January 29, 2013 2:46:01 PM EST

To: "[Assigned To]" <[Assigned To email?]>

Reply‐To: HUIT Support Center <[email protected]>

[Incident Number] (Incident Number will be a hyperlink to the Incident) has been assigned to your group

‘[Assignment Group]’.

Service Type: [Incident/Request]

Priority: [Priority]


Name: [Assigned To]

Location: [Assigned to Location?]

[LINK?]

https://remedy.fas.harvard.edu/arsys/forms/fasit‐rem‐

ars.fas.harvard.edu/HPD%3AHelp+Desk/?qual='Case%20ID*%2B'%3D%22INC000000556194%22

(Example)

Notes: [Comments FROM User?]


Incident Management



Assigned to an individual email

From: HUIT Support Center <[email protected]>

Subject: Incident [Incident Number] (Incident Number will be a hyperlink to the Incident) has been

assigned to YOU. Priority: [Priority]. Summary: [Short Description]

Date: January 29, 2013 2:46:01 PM EST

To: "[Assigned To]" <[Assigned To email?]>

Reply‐To: HUIT Support Center <[email protected]>

[Incident Number] (Incident Number will be a hyperlink to the Incident) has been assigned to you.

Service Type: [Incident/Request]

Priority: [Priority]


Name: [Assigned To]

Location: [Location?]

[LINK?]

https://remedy.fas.harvard.edu/arsys/forms/fasit‐rem‐

ars.fas.harvard.edu/HPD%3AHelp+Desk/?qual='Case%20ID*%2B'%3D%22INC000000556194%22

(Example)

Notes: [Comments FROM User?]


Incident Management



Resolution email Your support request, [Incident Number], has been resolved

Dear [Requestor Name],

Your support request, [Incident Number] (Incident Number will be a hyperlink to the Incident) has been

resolved, summarized as “[Short Description]”.

The technician added the following message at resolution: “[Close Notes]”

We strive to provide excellent customer service to all of our clients. If you feel your issue has not been

resolved, or you have received this message in error, please contact us for assistance via email at

[email protected] or by phone at 617‐495‐7777.

Sincerely,

Harvard University Information Technology HUIT Support Services Central Administration Support (617) 495‐8411 FAS Support (617) 495‐9000 HUIT Support (617) 495‐7777 [email protected] http://huit.harvard.edu Was this helpful? Survey Link: https://remedy.fas.harvard.edu/arsys/shared/FollowupSurvey.jsp


Incident Management



Figure 11 ‐ Current Resolution email


Incident Management



Survey Questions Survey Link: https://remedy.fas.harvard.edu/arsys/shared/FollowupSurvey.jsp


Incident Management



Reports The Critical Success Factors (CSF) and Key Performance Indicators outlined in the Process Description

should drive standard reporting for the process at this time and are listed below.

Incident Management

Report Title: Average Resolution Time Mean time to achieve Incident resolution or circumvention, broken down by impact code

Service 1 – University

Wide

2 – Multiple

Groups

3 – Single Group 4 ‐ Individual

Service A Ave. resolution

time

Ave. resolution

time

Ave. resolution

time

Ave. resolution

time

Service B Ave. resolution

time

Ave. resolution

time

Ave. resolution

time

Ave. resolution

time

Total All Services Ave. resolution

time

Ave. resolution

time

Ave. resolution

time

Ave. resolution

time

Report Title: First Call Closure Report Percentage of Incidents closed by the Service Desk without reference to other levels of support (often

referred to as ‘first point of contact’)

Service Name Total Incidents Percent of Total Closed on First

Call

Service A Total Incidents per period % of total Incidents per period

closed on first call

Service B Total Incidents per period % of total Incidents per period


Total All Services Total Incidents per period % of total Incidents per period



Incident Management



Report Title: Incident Volume

Total numbers of Incidents (as a control measure)

Report Title: Incident Backlog Size of current Incident backlog for each IT Service

Figure 12 ‐ Incident Backlog (Number of Incidents by Service)

Change to Service


Incident Management



Report Title: Major Incidents Number and percentage of Major Incidents for each IT Service

Service Name Total Incidents Percent of Total Closed on First

Call

Service A Total Major Incidents per period % of total Major Incidents per

period closed on first call

Service B Total Major Incidents per period % of total Major Incidents per


Total All Services Total Major Incidents per period % of total Major Incidents per


Report Title: Customer Satisfaction Average user/customer survey score (total and by question category)

<mock‐up of current HUIT report> (Should we put sample reports in the Appendix or a link)

Report Title: Survey Response Rate Percentage of satisfaction surveys answered versus total number of satisfaction surveys sent

Students # surveys sent # surveys answered Response Rate % Faculty # surveys sent # surveys answered Response Rate % Staff # surveys sent # surveys answered Response Rate %

Report Title: Incident Targets Percentage of Incidents assigned within agreed time (Incident response‐time targets may be specified in

SLAs, for example, by impact and urgency codes)

Production Incidents

Priority Total Incidents # Incidents & % of

Incidents meeting

assignment target

# Incidents & % of

Incidents meeting

resolution target

1 – Major Incidents Total Incidents # Incidents & % of # Incidents & % of


Incident Management



Incidents meeting

assignment target

Incidents meeting

resolution target

2‐ High Total Incidents

# Incidents & % of

Incidents meeting

assignment target

# Incidents & % of

Incidents meeting

resolution target

3 ‐ Moderate Total Incidents

# Incidents & % of

Incidents meeting

assignment target

# Incidents & % of

Incidents meeting

resolution target

4 ‐ Normal Total Incidents

# Incidents & % of

Incidents meeting

assignment target

# Incidents & % of

Incidents meeting

resolution target

Desktop Incidents

Priority Total Incidents

# Incidents & % of

Incidents meeting

assignment target

# Incidents & % of

Incidents meeting

resolution target

1 – Major Incidents Total Incidents

# Incidents & % of

Incidents meeting

assignment target

# Incidents & % of

Incidents meeting

resolution target

2‐ High Total Incidents

# Incidents & % of

Incidents meeting

assignment target

# Incidents & % of

Incidents meeting

resolution target

3 ‐ Moderate Total Incidents

# Incidents & % of

Incidents meeting

assignment target

# Incidents & % of

Incidents meeting

resolution target

4 ‐ Normal Total Incidents

# Incidents & % of

Incidents meeting

assignment target

# Incidents & % of

Incidents meeting

resolution target


Incident Management



Report Title: Assignment Accuracy Number and percentage of Incidents incorrectly assigned (re‐assigned at least 3 times)

Change to Service


Incident Management



Report Title: Categorization Accuracy Number and percentage of Incidents incorrectly categorized

Report Title: Service Desk Workload Number and percentage of Incidents processed per Service Desk agent

Agent Total Incidents in period % of total Incidents in period

Incident backlog filtered by [Assignment Group]

Change to Service


Incident Management



Generic Requests

Report Title: Request Handling Time The mean elapsed time for handling each type of service request

Generic Requests Desktop Requests

Request Type Average time to Fulfill Request Type Average time to Fulfill

Urgent Urgent High High Medium Medium Normal Normal

Report Title: Request Targets The number and percentage of service requests completed within agreed target times

Generic Request Type Total Number of Requests Number within Target % within Target Urgent High Medium Normal Desktop Request Type Total Number of Requests Number within Target % within Target Urgent High Medium Normal

Report Title: Service Desk Fulfillment Percentage of service requests closed by the Service Desk without reference to other levels of support

(often referred to as ‘first point of contact’)

Total Requests Total Requests Assigned to Service Desk (filter w/o escalation)

Report Title: Request Volume

Total number of requests (as a control number)


Incident Management



Report Title: Request User Satisfaction

Level of user satisfaction with the handling of service requests (as measured in some form of satisfaction survey)

Report Title: Request Backlog

The size of the current backlog of outstanding service requests

Assignment Group Open Requests Daily Weekly Monthly

Integration Requirements

Event Driven Integrations

Inbound Email (For outbound email/notification see the section, Notifications)

From users

Create/Update Incident Students, Faculty and Staff will need to be able to open Incidents and Generic Requests via Email. The

system must associate the e‐mail address with a specific queue (assignment Group) or a generic queue

for the Service Desk.

The system will need to be able to open a ticket without a contact, and preferably will be able to check

upon submission on known e‐mail addresses and affiliates (e.g., g‐mail address). The integration will

need to be capable of resolving to multiple alternate email addresses.

The Service Desk or the Assignment Group will assign the ticket to a specific individual.

Students, Faculty and Staff will need to be able to update Incidents and Generic Requests via Email by

replying to the confirmation email. The system should add the user comments to the existing ticket.

The system will provide a mechanism to prevent e‐mail looping (i.e., the Contact replies with a ‘thank‐

you’ response).


Incident Management



From event management

Create/Update Incident Automated systems such as monitoring tools should be able to open tickets via email in a similar

manner as above. The data mapping between the trouble ticketing system and the monitoring tool must

have a pre‐defined interface specification, typically with the following data:

Tag at beginning and end of message to indicate a single alarm

Alarm priority

Component type

Component Name

Problem Description

The trouble ticketing system should generate an Incident that corresponds to the information sent by

email, record and maintain alarm ID and Incident ID mapping so that when the status of an existing

alarm changes the corresponding Incident ID is automatically updated with the change.

The system will provide a mechanism to prevent e‐mail looping (i.e., the system will recognize multiple

Incidents from the same source within a given interval).

BatchLoaded Integrations

Contact information

Faculty & Staff

Students

Field Name Description Required?

HUID X

First Name X

Last Name X

Title X

VIP Status/Special

Handling ? X

School Code X

Employee Status Active, Terminated, Leave with Pay, etc.

Student Status Undergrad, Grad, Alumni, etc.

Last Update Last date profile was updated X

Photo


Incident Management



Table 10 ‐ Customer Record Data Fields

Authentication

Single Signon HUIT will implement the tool in June using a tool‐specific username and password combination. This is

the same authentication mechanism in‐use with Remedy today.

Once the Harvard SAML 2.0 infrastructure is in production, our intent is to migrate to SAML 2.0 and the

HUID/PIN authentication.

Technical Design Requirements

Workflow Configuration Requirements

Primary email Work

Email 2 Personal

Email 3 Alt 1

Email 4 Alt 2

Email 5 Alt 3

Work Phone Instead of 'primary', 'secondary' can we identify as 'work', 'mobile', 'home', 'lab', etc.?

X

Ext X

Mobile Phone

Home Phone

Lab Phone

Other Phone

Department No.

Department Name X

Primary Location Address X

Primary Room No. X

Alternate Contact Name

Alternate Contact Phone

Alternate Contact Email


Incident Management



Security Incidents

1. Tickets will be viewable by group; i.e., if it is security‐related it will only be visible to the security

group

2. There will be a flag check box to mark an Incident as high security, which would restrict visibility

of the ticket to a pre‐defined list

3. Additional individuals or groups may be added by users with appropriate privileges, using a

‘watch list’ feature tailored to security requirements

The June release has not identified specific workflow requirements. However, the system will provide

for the creation and use of Incident Models when defined.


Incident Management



The following information is specific to functionality that will be available after the June release.

Employee SelfService (for Incidents & Generic Requests) The ServiceNow application provides a Self‐Help application that is integrated into the Incident

Management application as well as other applications. After the initial release of Incident Management,

the use of Self‐Service will be limited to:

Reporting / Viewing Incidents

Recording Generic Requests

Changing profile information and passwords

Area 1 ‐ Navigation Content Block Field Name Description

Self‐Service Dropdown to navigate to Self‐Service screens

Homepage Service Catalog Knowledge Help the Help Desk Incidents Watched Incidents My Requests Requested Items Watched Requested Items My Profile Take Survey

Table 11 – Self‐Service Home Page Fields

Hidden: Problem, Change, Configuration, Service Catalog, BSM Map, Social IT

SelfService Portal Figure 5 illustrates the home page for the Self‐Service Portal.


Incident Management



Figure 13 ‐ Self Service Portal

Area 1 ‐ Navigation Content Block Links to: Homepage, Help the Help Desk, Incidents, Watched Incidents,

Hidden: Service Catalog, Knowledge, My Requests, Requested Items, Watched Requested Items

Area 2 – Main Content Block Field Name Description

Incident number Auto‐generated number. Can mask to ‘Number’

Short Description Text Contact Name of contact Table 12 –Self‐Service Portal Fields


Self‐Service�� Search�

Quick�Links�

FAQ�

News�


Incident Management



Area 3 – Information Snippets

Incident Task (Generic Request) Screen (main content area) The Incident Task (Generic Request) screen contains the following content blocks:

Incident Task

Figure 12 illustrates the Incident Task (Generic Request) content block

Figure 14 – Request

Incident Task Block ‐ FIELDS Required


Task Number Auto‐generated number. Default mask is

‘Number’ String Y Y

Short Description Text Text Y Y

Requested Item Not Used

Due Date The date the user would like the request

fulfilled

Date N N

Approval Not used

State Not used Reference Y Y

Parent Displays the Incident number of the ticket

the task relates to; auto‐filled by the

system

Reference N N

Requested for Name of person that wants the request Text Y Y


Incident Management



fulfilled

Assignment Group If not resolved by first line group, the default is

based on category / service / symptom Y Y

Assigned To Name of individual that the Incident is

assigned to Y Y

IT Watch List Multiple people that are automatically

informed of work notes associated with the

ticket; default field mask is ‘Work notes list’

Icon N N

Additional comments Text box for adding additional instructions as

required

Text N N

Table 13 ‐ Incident Task Block Fields

Portal Screen(s) (end user role) The following screens are relevant to the Self‐Service portal for end‐users.

Catalog Item ‐ Create a New Incident

Figure 16 illustrates the Create a New Incident screen

Figure 15 ‐ Create a New Incident

Create a New Incident (Self‐Service) Block ‐ FIELDS Required


Requestor Name of person requesting service; (has a

lookup button); field mask is ‘Open on

Reference Y N


Incident Management



behalf of this user’

Previous incident? Drop‐down choice; Yes or No; will have

helper text explaining what this means

Drop down Y N

Short description Text field Text Y N

Impact A drop‐down choice; 1) University‐wide,

2) Multiple Groups, 3) Single Group, 4)

Individual

Drop‐down Y N

Please describe your

issue below

Extended text field for details of incident Text N N

Table 14 ‐ Create New Incident (Self‐Service) Block Fields

Appendix

Approval

Name, Title Decision Date

Decision can be “Approved”, “Denied”, or “Need more Information”.

huit functional tech spec...

Documents