Service Desk Manager
End User Guide
This document is tailored for analysts and encompasses common usage issues associated with the
SDM ticketing software. It is assumed that analysts are familiar with the priority scale used for
rating Incidents and Requests. Information on IT Services Service Level targets and priority
definitions are located at https://intranet.uwmedicine.org/BU/IT/Pages/SDM-Service-LevelTargets.aspx.
Table of Contents
System Requirements ..................................................................................................................3
Access .........................................................................................................................................3
Support .......................................................................................................................................3
Application Changes.....................................................................................................................3
Best Practices ..............................................................................................................................5
Ticket Documentation...................................................................................................................... 5
Priority Assignment .......................................................................................................................... 5
Closing Confirmation........................................................................................................................ 6
Critical Incident Help Desk Notification ........................................................................................... 6
Group Ticket Queue Management .................................................................................................. 6
Ticket Transfers ................................................................................................................................ 6
Escalations ....................................................................................................................................... 7
Quick Profile ................................................................................................................................8
Accessing the Quick Profile .............................................................................................................. 9
Information .................................................................................................................................... 10
Ticket History ................................................................................................................................. 11
Scratchpad ..................................................................................................................................... 12
Creating Tickets.............................................................................................................................. 13
Creating Tickets from Template..................................................................................................... 14
Incidents.................................................................................................................................... 16
1
Creating Incidents .......................................................................................................................... 16
Status Codes................................................................................................................................... 20
Requests.................................................................................................................................... 22
Creating Requests .......................................................................................................................... 22
Status Codes................................................................................................................................... 26
Change Orders ........................................................................................................................... 28
Creating Change Orders ................................................................................................................. 28
Status Codes................................................................................................................................... 36
Impact Codes ................................................................................................................................. 38
Type Codes ..................................................................................................................................... 38
Risk Codes ...................................................................................................................................... 40
Change Types ................................................................................................................................. 41
Change Calendar ........................................................................................................................ 42
Accessing the Change Calendar ..................................................................................................... 42
Export iCalendar events ................................................................................................................. 43
Change Advisory Board (CAB) Console .......................................................................................... 43
CAB Components ........................................................................................................................... 45
Searching ................................................................................................................................... 49
Wildcards ....................................................................................................................................... 49
Go Button ....................................................................................................................................... 49
Ticket Searches .............................................................................................................................. 51
Parent / Child Tickets ................................................................................................................. 53
Creating Parent / Child Tickets ...................................................................................................... 53
Viewing Associations...................................................................................................................... 55
Closing All Child Tickets.................................................................................................................. 56
Attachments .............................................................................................................................. 57
Document Attachments ................................................................................................................. 57
URL Attachments ........................................................................................................................... 58
Application Customization ......................................................................................................... 61
Scoreboard ..................................................................................................................................... 61
Notifications .............................................................................................................................. 73
Notification Methods ..................................................................................................................... 73
Notification Types .......................................................................................................................... 76
Affected End User .......................................................................................................................... 77
Assignee Notifications.................................................................................................................... 77
Group Notifications........................................................................................................................ 78
Manual Notifications...................................................................................................................... 79
Glossary..................................................................................................................................... 81
Appendix A: Keyboard Shortcuts ............................................................................................... 85
2
System Requirements
The Service Desk Manager client is accessible from Windows based PCs running later revisions of
Internet Explorer or Firefox 4.0.1.
Access
SDM can be accessed directly through a web browser by utilizing the URL
https://helpdesk.uwmedicine.org. An active UW Medicine login ID and password is required for
system access. Accounts must be designated as analysts within the system to view the standard
Analyst interface. Group managers can contact the Help Desk to initiate this configuration change.
Support
Application errors or usage questions should be reported to the IT Services Help Desk at
mcsos@u.washington.edu or via phone at 206.543.7012. Analyst, group, template, category,
configuration item or scoreboard query configuration requests can be made by SDM request ticket
to the SDM group or through the Help Desk.
Application Changes
The Service Desk Manger 12.7 release includes a number of new and augmented features to help
facilitate a streamlined approach to Change Management, and general enhancements to other
application functions. Change order modifications, unless otherwise stated will generally retain the
same functionality as the previous release
Impacts, Urgencies, Priority levels
IT Services has published a set of Impact, Urgency and Priority levels. These are encompassed
within the Service Level Targets documentation.
Change Control Calendar
All Analysts will have access to a tab labeled “Change Calendar”. The Change Calendar displays a
graphical view of change events, including all scheduled, failed, and in-progress changes in a
configurable calendar view. The calendar also displays black-out dates, which are freeze periods.
3
CAB Console
A Change Advisory Board (CAB) Console has been provided as a dashboard interface that facilitates
quick online management of change orders requiring CAB approval. The CAB console is tailored for
group or department Change Managers.
Exportable Results
Service Desk Manager now has an [Export] button available from search results pages that allow for
saving information to Excel or Adobe PDF documents. ICalendar files that can be utilized by
Microsoft Outlook can be created based on entries on the Change Calendar.
4
Best Practices
Ticket Documentation
Priority Assignment
Closing Confirmation
Critical Incident Help Desk Notification
Group Ticket Queue Management
Ticket Transfers
Escalations
Ticket Documentation
 Information obtained from the customer upon ticket creation should include enough
information to be actionable by the receiving analyst without the need to contact them for
additional information.
 Closing comments should fully detail what was done to resolve the issue. Closing comments are
often utilized to determine ticket ownership, identify recurring issues, and provide resolution
steps. Consistently listing detailed closing comments will reduce the number of easily resolvable
issues routed to second tier support groups.
 By default customers are notified via email on ticket creation and closure. Well written and
grammatically correct text helps to present the department’s professionalism.
 When work has been performed on a ticket it should be documented utilizing the ‘Log
Comment’ feature available from the ticket’s Activity window. When a customer is notified by
external email or via a phone call it should be tracked using this feature.
 When transferring a ticket to another group or analyst the reason for the transfer should be
thoroughly articulated.
 Incident tickets should be updated within one business day of the task being completed.
Request tickets should be updated at a minimum of once per week.
Priority Assignment
 When creating an Incident within the system utilize the Impact and Urgency to determine the
appropriate Priority.
5
 When creating a Request or Change order assign the ticket Priority based on the Priority
Definitions policy. The Priority Definitions policy can be found at
https://intranet.uwmedicine.org/BU/IT/Pages/SDM-Service-Level-Targets.aspx. If there is any
doubt or question on priority assignments refer the ticket to the IT Services Help Desk.
 Incident priorities are set based on the customer impact and urgency as listed on the Service
Level Targets definitions webpage. Impact and urgency fields should not be artificially raised or
lowered to adjust the perceived response time or default activity notification method. If a
response rate is required that is outside the defined SLT the receiving analyst or group oncall
should be contacted for escalation coordination.
Closing Confirmation
 Confirmation from the customer that an incident has been resolved should be obtained before
closing a ticket. In the event that the customer does not respond after repeated inquiries it is
permissible to close a ticket after giving adequate forewarning that details what is being done
and why.
Critical Incident Help Desk Notification
 Critical Incidents by nature are urgent and affect the UW Medicine organization in its entirety.
This class of Incident typically requires the initiation of downtime procedures which may include
mass notifications, updating customer facing voice response, and conference call coordination.
When a critical Incident has been identified report it to the Help Desk by phone at 206.543.7012
as soon as possible.
Group Ticket Queue Management
 The manager of each group is accountable for maintaining their ticket queue. Queues must be
monitored diligently to prevent tickets from being open in the queue without receiving
attention.
Ticket Transfers
 A formal communication must take place to agree on the transfer between the original owner of
the ticket and the new assignee; this can be done via the Comments section within the ticket
(preferred), email, phone, or direct conversation.
 If there is a question regarding the appropriate category or whom the ticket should be
transferred to, you should refer to your group manager for a decision. If it is still unclear then
direct the ticket back to the IT Services Help Desk for the correct assignment.
 If a there is a disagreement about a misrouted transfer the first step is to discuss the issue with
the original owner. If it cannot be resolved escalate it to your group manager for a decision on
who should own the ticket. Until the disagreement is resolved the new assignee remains the
6
owner of the ticket and has the responsibility to contact the customer and tactfully let them
know that the issue is being addressed.
Escalations
 Tickets should only be escalated if after an assessment an issue is determined to have a broader
scope than first thought (Server down, network outage, more customers affected). Conversely,
tickets should be de-escalated if the impact is less than originally conveyed or at the request of
the Affected End User.
7
Quick Profile
The Quick Profile provides a centralized area to view detailed information about a contact.
Information available includes contact and organization information, environment, ticket history
details and additional information. Additionally the Quick Profile provides the means to create a
new ticket, populating information from a contact record. New tickets can be created with or
without utilization of a ticket template.
The Quick Profile is divided into three panes. The left pane [1] is the menu of the contact’s general
information, environment, and ticket history. The right pane [2] displays the results of the menu
selection. The bottom pane [3] shows the Scratchpad area. The Scratchpad allows the Analyst to
take notes or comments and add them into the Description section of an Incident, Request, or
Change Order.
8
Accessing the Quick Profile
Information
Ticket History
Scratchpad
Accessing the Quick Profile
1) The Quick Profile is accessed by selecting the corresponding tab from the main interface.
2) Search for the customer utilizing the ‘Last Name’, ‘First Name’ or ‘System Login’ fields. Click the
[Search] button.
3) Select the name of the customer from the Quick Profile Contact List.
9
Information
The Information section of the Quick Profile includes general information about the contact. This
includes the contact name, login, system access levels, phone numbers, email address and notes. To
access the Information section, select the Information link from the left hand pane within the Quick
Profile.
To update information listed for a contact select the [Edit This Contact] button.
Note: Analysts can only modify their own contact record and records for customers assigned the
‘Employee’ Access Type. To request an update to another Analyst contact, create a ticket to the
SDM group or contact the IT Services Help Desk.
10
Ticket History
A contact’s ticket history is available for each ticket type. Links are listed in the left pane of the
Quick Profile for the Incident History, Request History, Problem History, Requester History and
Change Order History. Selecting a link provides a historical reference of tickets associated to the
contact. After selecting a specific history link the associated ticket(s) will display in the right hand
pane.
11
Scratchpad
The Scratchpad section is utilized for writing ticket descriptions and creating new tickets for the
selected contact. Tickets created through the Scratchpad will auto populate with the contact’s
information.
12
Creating Tickets
Creating Tickets from Template
Creating Tickets
1) Search for the contact record of the Affected End User.
2) Enter information into the Scratchpad.
3) Select the desired type of ticket from the Type dropdown menu. Request, Incident, or Change
Order tickets are available.
13
4) Click the [New] button. This will launch a new ticket window for the type of ticket selected.
Note: Information typed in the Scratchpad text box will automatically populate in the Description
field within the ticket. While not required, this is a useful way to gather information for a new ticket.
Creating Tickets from Template
1) Select the desired type of ticket from the Type dropdown menu. Request, Incident, or Change
Order tickets are available.
2) Click the Template field lookup.
14
3) Select the appropriate template from the pick list.
4) Click the [New] button. This will launch a new ticket window for the type of ticket selected with
information populated from the template.
15
Incidents
An incident is an event which is not part of the standard operation of a service and which causes or
may cause disruption to or a reduction in the quality of services and customer productivity.
Incidents are considered Break / Fix events.
Creating Incidents
Status Codes
Creating Incidents
1) Log into SDM with your UW Medicine login and password.
2) Select ‘New Incident’ from the File menu. The form “Create New Incident ###” opens.
3) Choose the ‘Affected End User’ field icon. A Contact Search form will open.
4) Type the System Login, Last Name, First Name, or a partial name into the respective search
boxes and click the [Search] button.
16
5) Choose the appropriate name from the list. The information will automatically populate the
Affected End User field.
6) Choose the Category field icon.
7) Expand and select the appropriate category from the selection tree. This will populate the
Category field.
Note: Many categories have a default Group associated with them. Selection of the category will
auto-populate the ‘Group’ field and can be overwritten as needed.
8) If the Group field is empty choose the Group field icon. A Group List selection screen will open.
17
9) Select the appropriate Group from the pick list. This will populate the Group field.
10) Select both the Impact and Urgency from their respective dropdown boxes. Utilize the criteria
outlined in the IT Services Service Level Targets for correct assignments.
18
11) Enter a concise summary of the incident into the Summary textbox. Enter a thorough
description of the incident including all symptoms, error messages, customer location(s), contact
information, and troubleshooting steps completed into the Description textbox.
Information has now been added to all required fields. Required fields are followed with an asterisk.
12) Enter the name of the Assignee in Last Name, First Name format if required.
13) Attach any documents if necessary.
19
14) Create child tickets or associate to a parent ticket if necessary.
15) Click the [Save] button.
Status Codes
Status Codes are used to reflect the state of an Incident. Proper Status Code use and assignment is
utilized to properly adhere to published Service Level Agreement response and resolution times and
for reporting, trending and Problem identification and resolution.
Awaiting Approval
Awaiting User Response
Awaiting Vendor
Closed
Closed-Unresolved
Hold
In Progress
Open
Pending
Researching
Awaiting Approval
The Awaiting Approval status code is applicable to Incidents and Requests and is used to indicate
that required authorization has not yet been obtained. This authorization must be given before the
issue request or fix can be facilitated. The individual(s) that must supply the approval must be
added in the ticket comments.
Awaiting User Response
The Awaiting User Response status code is applicable to Incidents and Requests and is utilized to
indicate that the ticket has been placed in a hold state pending a response from the Affected End
User.
Awaiting Vendor
The Awaiting Vendor status code is applicable to Incident and Requests and is utilized to indicate
that the ticket has been placed in a hold state pending a vendor action or response.
20
Closed
The Closed status code is applicable to Incidents and Requests and is utilized to indicate that an
issue has been successfully resolved. A ticket should not be placed in a closed state until receiving
Affected End User confirmation that it has been resolved satisfactorily.
Closed – Unresolved
The Closed-Unresolved status code is applicable to Incidents and Requests and is utilized to indicate
that an issue has not been successfully resolved and that additional work will not be performed.
This code should be utilized when a customer cannot be notified for confirmation of successful
completion after repeated attempts, if a workaround to an issue was provided and agreed to by the
customer, or if there is no viable way to facilitate the issue.
Hold
The Hold status code is applicable to Incidents and Requests and is utilized to indicate that an issue
has been reviewed by the receiving analyst and put in hold to stop the Service Level Agreement
resolution target set by the ticket Priority. Hold should be utilized when an issue is perceived to be
resolved and the customer is being contacted for confirmation or if a request is waiting on an
external dependent service.
In Progress
The In Progress status code is applicable to Incidents and Requests and is utilized when work is
being actively done to determine a resolution for an issue.
Open
The Open status code is applicable to Incidents and Requests and is used to indicate that an issue is
Active.
Pending
The Pending status code is applicable to Incident and Requests and is used to indicate that the ticket
is waiting for the completion of a related Change Order, Incident, Request, Action Item or available
resource.
Researching
The Researching status code is applicable to Incidents and Requests and is utilized to indicate that
an issue has been reviewed by the receiving analyst and is actively being worked. Selection of the
Researching status code does not stop the Service Level Agreement resolution target set by the
ticket Priority.
21
Requests
Requests are petitions for new functionality. Requests are made for an increase of existing
functionality and are not used for Break / Fix events.
Creating Requests
Status Codes
Creating Requests
1) Log into SDM with your UW Medicine login and password.
2) Choose File>New Request. The form “Create New Request R###” opens.
3) Choose the “Affected End User” field icon. A Contact Search form will open.
4) Type the System Login, Last Name, First Name, or a partial name into the respective search
boxes and click the [Search] button.
5) Choose the appropriate name from the list. The information will automatically populate the
Affected End User field.
6) Choose the “Category” field icon.
22
16) Expand and select the appropriate category from the selection tree. This will populate the
Category field.
Note: Many categories have a default Group associated with them. Selection of the category will
auto-populate the ‘Group’ field and can be overwritten as needed.
7) Select the Priority from the corresponding dropdown box. Utilize the criteria outlined in the IT
Services Service Level Targets and priority definitions site for the correct assignment. Service
Level Targets are outlined at https://intranet.uwmedicine.org/BU/IT/Pages/SDM-Service-LevelTargets.aspx.
8) If the Group field is empty choose the “Group” field icon. A Group List selection screen will
open.
23
9) Select the appropriate Group from the pick list. This will populate the Group field.
10) Enter a concise summary of the Request into the Summary textbox. Enter a thorough
description of the request, in addition to the customer location and contact information in the
Description textbox.
24
Information has now been added to all required fields. Required fields are followed with an asterisk.
11) Enter the name of the Assignee in Last Name, First Name format if required.
12) Attach any documents if necessary.
13) Create child tickets or associate to a parent ticket if necessary.
14) Click the [Save] button.
25
Status Codes
Status Codes are used to reflect the state of a Request. Proper Status Code use and assignment is
utilized to properly adhere to published Service Level Agreement response and resolution times and
for reporting, trending and Problem identification and resolution.
Awaiting Approval
Awaiting User Response
Awaiting Vendor
Closed
Closed-Unresolved
Hold
In Progress
Open
Pending
Researching
Awaiting Approval
The Awaiting Approval status code is applicable to Incidents and Requests and is used to indicate
that required authorization has not yet been obtained. This authorization must be given before the
issue request or fix can be facilitated. The individual(s) that must supply the approval must be
added in the ticket comments.
Awaiting User Response
The Awaiting User Response status code is applicable to Incidents and Requests and is utilized to
indicate that the ticket has been placed in a hold state pending a response from the Affected End
User.
Awaiting Vendor
The Awaiting Vendor status code is applicable to Incident and Requests and is utilized to indicate
that the ticket has been placed in a hold state pending a vendor action or response.
Closed
The Closed status code is applicable to Incidents and Requests and is utilized to indicate that an
issue has been successfully resolved. A ticket should not be placed in a closed state until receiving
Affected End User confirmation that it has been resolved satisfactorily.
26
Closed – Unresolved
The Closed-Unresolved status code is applicable to Incidents and Requests and is utilized to indicate
than an issue has not been successfully resolved and that additional work will not be performed.
This code should be utilized when a customer cannot be notified for confirmation of successful
completion after repeated attempts, if a workaround to an issue was provided and agreed to by the
customer, or if there is no viable way to facilitate the issue.
Hold
The Hold status code is applicable to Incidents and Requests and is utilized to indicate that an issue
has been reviewed by the receiving analyst and put in hold to stop the Service Level Agreement
resolution target set by the ticket Priority. Hold should be utilized when an issue is perceived to be
resolved and the customer is being contacted for confirmation or if a request is waiting on an
external dependent service.
In Progress
The In Progress status code is applicable to Incidents and Requests and is utilized when work is
being actively done to determine a resolution for an issue.
Open
The Open status code is applicable to Incidents and Requests and is used to indicate that an issue is
Active.
Pending
The Pending status code is applicable to Incident and Requests and is used to indicate that the ticket
is waiting for the completion of a related Change Order, Incident, Request, Action Item or available
resource.
Researching
The Researching status code is applicable to Incidents and Requests and is utilized to indicate that
an issue has been reviewed by the receiving analyst and is actively being worked. Selection of the
Researching status code does not stop the Service Level Agreement resolution target set by the
ticket Priority.
27
Change Orders
Change Orders are tickets that address the addition, modification or removal of authorized, planned
or supported service or service component and its associated documentation. Change Orders are
typically associated with a group or the enterprise’s Change Control processes.
Creating Change Orders
Status Codes
Impact Codes
Type Codes
Risk Codes
Change Types
Creating Change Orders
All tickets types have some fields that require values in order to successfully save or close. These
fields can generally be identified by their labels, which are followed by an asterisk. In some instances
fields are conditionally required based on the ticket ‘Type’.
1) Log into Service Desk Manager with a valid UW Medicine login and password.
2) Select ‘New Change Order’ from the File menu. The form “Create New Change C####” opens.
28
3) Click the ‘Requester’ control to open the Contact Search form.
4) Enter a System Login, Last Name, First Name, or a partial name into the respective fields and
click the [Search] button.
5) Select the appropriate contact name from the list. The contact name will automatically
populate into the ‘Requester’ field in <Last Name>, <First Name>, <Middle Initial> format.
6) By default the Affected End User will populate with the same name as the Requester. If the
Affected End User needs to be changed click the ‘Affected End User’ field icon and repeat steps
4-5.
7) Click the ‘Category’ link. Expand and select the appropriate category from the selection tree.
This will populate the Category field.
Note: Commonly utilized change categories may also automatically populate fields such as the
‘CAB’, ‘Type’ and the Properties tab. Values for ‘CAB’ and ‘Type’ can be overridden as needed.
8) Select the Priority from the corresponding dropdown box. Utilize the criteria outlined in the IT
Services Service Level Targets and priority definitions site for the correct assignment. Service
Level Targets are outlined at https://intranet.uwmedicine.org/BU/IT/Pages/SDM-Service-LevelTargets.aspx.
29
9) Select the Type from the corresponding dropdown box. Valid change types are ‘Emergency’,
‘Express’, ‘Operational’ and ‘Routine’.
10) Select the Risk from the corresponding dropdown box.
11) If either the Assignee’s Group or Requesting Group fields are empty click the ‘Assignee’s Group’
or ‘Requesting Group’ field icons. A Group List selection screen will open.
12) The ‘Group’ field indicates the name of the group who will implement the Change Order. Select
the appropriate entry from the pick list.
30
13) Click the ‘CAB’ field icon. A Group List Search form will open. Select the name of the Group who
will review the Change Control ticket. To schedule a change order to be reviewed by the
Enterprise Change Control board, enter “ChangeControl” into the ‘CAB’ field.
14) Select the Impact from the corresponding dropdown box.
15) Select the ‘Need By Date’ link to display a calendar control. ‘Need By Date’ is the latest feasible
implementation date for the Change Order. The ‘Need By Date’ cannot be set to a date / time in
the past.
31
16) Select the ‘Schedule Start Date’ link to display a calendar control. Schedule Start Date
corresponds to the anticipated implementation Date and Time. The Schedule Start Date field
can utilize a date and time in the past.
32
17) Enter the Schedule Duration in the corresponding textbox. Times entered must be in hh:mm:ss
format.
18) Enter a concise summary of the Change Request into the ‘Order Summary’ textbox. Enter a
thorough description of the Change Request in the ‘Order Description’ textbox.
19) Select the Costs / Plans tab. This is a sub tab beneath the ‘Additional Information’ main tab.
20) Enter applicable information into the ‘Implementation Plan’, and ‘Backout Plan’ fields.
Note: The UW Medicine Enterprise Change Control process requires that values be entered into the
‘Implementation Plan’ and ‘Backout Plan’ fields for any change order assigned the ‘CC Routine’
category.
33
21) Select the Properties tab.
22) Selection of most Change Request categories will cause additional required questions to display
within the Properties tab. Required fields are indicated by a trailing asterisks.
34
23) ‘CC Emergency’ and ‘CC Express’ enterprise change orders require a value for ‘Authorized
Approver’. If applicable, enter the name of the approving manager in Last Name, First Name
format.
24) Enter the name of the Assignee in Last Name, First Name format if required.
25) Attach any documents if necessary.
35
26) Create child tickets or associate to a parent ticket if necessary.
27) Click the [Save] button.
Status Codes
Status Codes are used to reflect the state of a Change Order. Proper Status Code use and
assignment is utilized to trend and track successful changes to the IT infrastructure and helps to
facilitate the IT Services Quality Assurance group’s mission of providing quality assurance tools,
standards, processes, and methodologies that enable IT Services to deliver high availability and
continuous operations.
Approved
Cancelled
Closed
Conditionally Approved
Customer Hold
Defective
Deferred
Denied
New
Pending
Vendor Hold
Approved
The ‘Approved’ status code is utilized by the Change Control group to indicate that a request has
gone through the IT Services Change Control process and has been assigned to the implementing
group for inclusion into the production environment.
Cancelled
The ‘Cancelled’ status code is utilized by the Change Control group, the Affected End User or
Requester to indicate that a change request was closed but not implemented.
Closed
The ‘Closed’ status code is utilized by the implementing group to indicate that a request has gone
through the IT Services Change Control process and has been successfully implemented into the
production environment.
36
Conditionally Approved
The ‘Conditionally Approved’ status code is utilized by the Change Control group to indicate that a
request has gone through the IT Services Change Control process and has been assigned to the
implementing group for inclusion into the production environment once outlined preconditions
have been met.
Customer Hold
The ‘Customer Hold’ status code is utilized by the implementing group to indicate that the
Requester has requested a delay in implementation for the Change Order.
Defective
The ‘Defective’ status code is utilized by the Change Control or implementing group to categorize
requests that have gone through the IT Services Change Control process, were placed into the
production environment and were defective, or had to be removed from the production
environment.
Deferred
The ‘Deferred’ status code is utilized by the Change Control group, the Affected End User or
Requester to indicate that a change implementation will be postponed and considered inactive.
Denied
The Denied status code is utilized by the Change Control group to indicate that a request has gone
through the IT Services Change Control process and has not been approved for implementation into
the production environment.
New
The New status code is analogous to the RFC (Request for Change) status code and is used to
indicate that a request has been made but has not gone through the IT Services Change Control
process.
Pending
The Pending status code is utilized by the Change Control group to indicate that the request is in a
review state or is pending manager approval.
Vendor Hold
The ‘Vendor Hold’ status code is utilized by the implementing group to indicate that a change
cannot proceed, pending additional information or intervention from the system vendor.
37
Impact Codes
The ‘Impact’ field is an optional control located within the ‘Change Control’ section of Change Order
tickets. Although not required, selection of an applicable Impact code can be utilized by Change
Advisory Boards to help assess the overall impact to successful or unsuccessful deployments and
ensure that appropriate controls associated with those impacts, like adequate notifications for
example, are pursued.
Enterprise
The Change Order implementation will affect more than one UW Medicine campus.
Facility
The Change Order implementation will affect a single UW Medicine campus.
Departments
The Change Order implementation will affect multiple groups, either internal or external to a single
campus.
Multiple Users
The Change Order implementation will affect multiple users within a single group.
Single User
The Change Order implementation will affect a single user.
Type Codes
The ‘Type’ field is an optional control located within the ‘Change Control’ section of Change Order
tickets. The type codes available correspond to the four active Change Control categories ‘CC
38
Routine’, ‘CC Express’, ‘CC Operational’ and ‘CC Emergency’ and are utilized to color code events
within the Change Calendar and allow another mechanism to selectively filter results of Change
Order searches.
Routine
Express
Emergency
Operational
Routine
The ‘Routine’ value corresponds to the ‘CC Routine’ Change Order category. If a value in the ‘Type’
control of ‘Routine’ is selected and the Change Order is saved the event will display on the Change
Calendar in a light blue color with a banner display of “Normal”. This color code is shared with
‘Operational’ change orders.
Express
The ‘Express’ type corresponds to the ‘CC Express’ Change Order category. If the ‘Express’ Type is
selected and the Change Order is saved the event will display on the Change Calendar in a white
color with a banner display of “Standard”.
Emergency
The ‘Emergency’ type corresponds to the ‘CC Emergency’ Change Order category. If the
‘Emergency’ Type is selected and the Change Order is saved the event will display on the Change
Calendar in a red color with a banner display of “Emergency”.
39
Operational
The ‘Operational’ type corresponds to the ‘CC Operational’ Change Order category. If a value in the
‘Type’ control of ‘Operational’ is selected and the Change Order is saved the event will display on
the Change Calendar in a light blue color with a banner display of “Normal”. This color code is
shared with ‘Routine’ change orders.
Risk Codes
Risk codes are utilized along with the change order impact by Change Advisory Boards to help assess
the scope of a given implementation. Risk code selection within Change Order tickets are optional
to save.
1-Extreme
If the change fails, the extent of the impact is high, the probability of failures occurring is high, and
the anticipated recovery time is long.
2-High
If the change fails, the extent of the impact is high and the probability of failures occurring is high.
3-Medium
If the change fails, the extent of the impact is high and the probability of failures occurring is low, or,
if the change fails, the extent of the impact is low and the probability of failures occurring is high
4-Normal
If the change fails, the extent of the impact is medium and the probability of failures occurring is
low, or, if the change fails, the extent of the impact is low and the probability of failures is medium.
5-None
If the change fails, the extent of the impact is nonexistent or negligible.
40
Change Types
Change Types are specific to Change Orders and are used to categorize the type of implementation.
Proper categorization is used in trending and reporting on production environment change
successes and failures.
Enhancement
Adding new functionality or modifying existing functionality.
Break Fix
Adding fixes for failures.
Maintenance
Changes due to maintenance.
New Service
Providing a new service, including projects.
Version Upgrade
Upgrade to a newer version.
41
Change Calendar
The Change Calendar tab provides access to the schedule of events for changes planned for
implementation into the production UW Medicine environment. The Change Calendar tab is
available to all Service Desk Manager Analysts and allows them the ability to:
Accessing the Change Calendar
Export iCalendar events
Accessing the Change Calendar
The Change Calendar is accessible to all Analysts from the main Service Desk Manager
window. Click the ‘Change Calendar’ tab to display the contents.
The Service Desk Manager Change Calendar screens allow for numerous ways to filter results on the
change calendar. Hovering over any scheduled event on the Change Calendar will display
information on the change order ticket number, type, scheduled date / time, duration, summary,
and assigned analyst.
42
Export iCalendar events
Service Desk Manager now supports exporting of the full or filtered results of the Change Calendar
in iCalendar (.ics) format. iCalendar is a computer file format which allows Internet users to send or
utilize meeting requests and tasks to other users, most notably through the Microsoft Outlook
application.
To export, select the Change Calendar tab, apply one or more filters if desired, and select the
[Export] button.
Note: Some popup blockers may prevent the dialog allowing you to open or save the schedule.ics
file. Users who see a flash or rapidly closing window may bypass the popup blocker by holding down
the [Ctrl] button and clicking the [Export] button again.
Change Advisory Board (CAB) Console
The Change Advisory Board console, released with Service Desk Manager is a feature that presents a
dashboard for CAB managers or members to rapidly assess and classify owned Change Orders from
a single centralized location.
Accessing
CAB Components
Accessing
The [CAB Console] button is available from any Change Order search results screen. The most
common access points are through use of a Scoreboard query or through the Search > Change
Orders menu on the standard toolbar.
Scoreboard
Search Menu
Scoreboard
Using a Scoreboard query applies one or more pre-defined filters to a view of all Change Orders.
This effectively narrows the scope of results to those particular to situation, typically Change Orders
assigned to the logged in user’s group or assigned to the logged in user’s CAB.
43
1) Select the ‘My Created Change Orders’ link in the Scoreboard.
Note: Service Desk Manager Analysts may need to add the ‘My Created Change Orders’ link to the
Scoreboard. Utilize the Application Customization instructions located within the End User
Documentation for help on performing this update.
2) If applicable, narrow the scope of results by selecting the [Show Filter] button and adding
additional search criteria.
3) Change Orders will display within the CAB Console in the order that they are listed in the Search
Results window. To change the order of displayed tickets click the appropriate hyperlink
included in each column header to sort in ascending or descending order.
44
4) Click the [CAB Console] button.
CAB Components
This section outlines the features and functions of the Change Advisory Board console.
Standard Toolbar
Comments
New Status
Change Order Details
Properties
Attachments
Standard Toolbar
The CAB Console standard toolbar contains buttons to streamline the approval and Change Order
transition process.
45
Previous
The [Previous] button accesses the details of the previous Change Order in the list. If the Change
Order is already the first in the list this button will be inactive.
Next
The [Next] button accesses the details of the next Change Order in the result list. If the Change
Order is already the last in the list this button will be inactive.
Edit Change
The [Edit Change] button opens the currently displayed Change Order in a new window. This allows
the ticket to be edited and saved without the need to toggle between the CAB console and the main
interface
Comments
Information added into the Comments textbox will be included into the ticket’s event log only if one
of the [Approve Change], [Conditional], or [Reject Change] buttons are selected. Information added
into the Comments field will not be recorded if the Status is modified through the ‘Status’ dropdown
box, or if the [Previous] or [Next] buttons are selected.
New Status
Allows changing of a ticket’s status code without needing to go into the ticket edit mode.
46
Change Order Details Tab
The ‘Change Order Details’ tab is a summarized representation of the content from the original
ticket body and information from the ‘Plans’ tab, including the ‘Implementation Plan’ and ‘Backout
Plan’.
Properties Tab
The ‘Properties’ tab is a summarized representation of the Properties tab originally populated upon
saving of the Change Order. Note that some Change Order categories do not have any properties
and thus would not be reflected within the tab.
Attachments Tab
The ‘Attachments’ tab is a mirror of the Attachments tab found on the original Change Order.
Workflow Tasks Tab
47
The ‘Workflow Tasks’ tab displays associated workflow tasks designed within IT Process Automation
Manager. Note that there are currently no Workflows associated with Change Management.
Config. Items Tab
Displays Configuration Items associated with the Change Order
48
Searching
Search forms can be accessed through use of the search dropdown on the upper right hand corner
of the main SDM and ticket screens, and through the items listed on the Search menu. Additionally,
reference data within the system can be searched.
Wildcards
Go button
Ticket Searches
Wildcards
SDM supports the use of wildcards in all lookup fields. Supported wildcards include the % sign and
the _ character.
The % sign is used as a wildcard for multiple characters. For example, searching Last Names using J%
would return a list of all contacts whose Last Name started with the letter J.
The _ sign is used as a wildcard for single characters. For example, searching First Names using _e_
would return a list of all contacts whose First name is three characters long with the middle
character being an e.
Go Button
The Go Button Search box is available from the main SDM screen and all ticket windows. The Go
button is useful when specific information, such as ticket number or user specific information is
available. Because wildcards can be used the Go Button Search box can still be utilized even if only
partial information is known.
49
Change Order
Req/Inc
Knowledge
Document by ID
User by ID
User by Phone
User by Name
Change Order
Used to search for Active or Inactive Change Order tickets. All Change Order tickets numbers must
prefaced with the letter C (i.e. C1000). The Change Order number of the ticket must be entered
exactly to return a single result. The % or _ wildcards can be used to return a larger number of
results.
Requests/Incidents
Used to search for Active or Inactive Request or Incident tickets. The number of the ticket must be
entered exactly to return a single result. The % or _ wildcards can be used to return a larger number
of results.
Knowledge
Used to search for Knowledge Articles by keyword. If multiple keywords are entered and one or
more match the contents of a Knowledge Article a result will be returned. The % or _ wildcards can
be used to return a larger number of results.
50
Document by ID
Used to search for Knowledge Articles by the Document ID. The Document ID of the Knowledge
Article must be entered exactly to return a result. Wildcards cannot be used when searching by
Document ID.
User by ID
This is used to search for active contact records by System Login. The System Login of the contact
must be entered exactly to return a single result. The % or _ wildcards can be used to return a larger
number of results.
User by Phone
This is used to search for active contact records by Phone Number. The Phone Number of the
contact must be entered exactly to return a single result. The % or _ wildcards can be used to return
a larger number of results.
User by Name
This is used to search for active contact records by Name. Information must be entered in Last
Name, First Name format. The % or _ wildcards can be used to return a larger number of results.
Ticket Searches
Tickets can be searched with granularity by utilizing the Incident, Request and Change Order screens
available from the Search menu. Assignment Status, End User Name, Assignee, Group, Priority,
Open Date, and Summary are a few examples of search filters that can be applied.
51
There are three types of search fields available within SDM. The first is a lookup field and is denoted
with a magnifying glass icon. Selecting the magnifying glass will launch a search screen that can be
used to narrow the scope of the selection list.
Selecting a list menu icon, denoted by the plus sign icon, will launch a pick list in tree format.
Selection of an entry from the pick list will populate the field.
Note: Items listed in black text are not selectable.
Selecting a calendar menu icon, will launch a Date Menu Helper screen. Selection of a date and time
will populate the field.
52
Parent / Child Tickets
Parent and Child tickets are used to group incidents, requests or change orders. This Parent / Child
linkage is logged within each associated ticket. Having this association provides a visual mechanism
to quickly assess an issue’s impact and allows readily available access to related ticket reference
data.
Because Parent and Child tickets are used for ticket grouping they are utilized to document work
done on a single issue that is either reported by many people or that is multi-part and involves work
to be performed by numerous groups within SDM.
In the case of a single issue reported by multiple end users, when the primary source of the issue is
resolved the Parent ticket can be closed, then all Children can be closed in a single step, all with the
same closing comments. This provides significant time savings over having to enter the closing
comments into each ticket individually.
In the case of a multi-part ticket, Child tickets are spawned from the Parent for a subset of work to
be performed. Once all subsets of the work have been completed, the Parent is closed.
Creating Parent / Child Tickets
Viewing Associations
Closing All Child Tickets
Creating Parent / Child Tickets
1) Perform the steps to create and save a ticket as outlined in the Creating Incidents, Creating
Requests, or Creating Change Orders sections of this document.
Method 1
a. Select the Relationships main tab. Select the Parent/Child sub tab.
53
b. Click the [Child Incident] or [Child Request] button. This open a copy of the original ticket in
edit view. Additionally the Parent field on the child ticket displays the ticket number of the
source ticket. Saving the ticket will establish the Parent / Child relationship.
Method 2
a. Create another ticket of the same type (i.e. Incident, Request, Change Order) but do not click
the [Save] button.
b. Select the Relationships main tab. Select the Parent/Child sub tab. In the Parent field, enter the
number of the ticket created in Step 1. Click the [Save] button. The ticket created in step one is
now designated as the Parent ticket to the Child ticket created in Step 2.
54
Viewing Associations
1) Perform the steps to search for and open an Incident, Request, or Change Order ticket as
outlined in the Searching section of this document.
2) After accessing the ticket, click on the Parent / Child tab to view applicable Parent/Child
associations. If the selected ticket is a Child, the Parent ticket will be listed in the Parent section.
Alternately, if the selected ticket is a Parent, the Child ticket(s) will be listed in the Child section.
55
Updating Child Ticket Status
1) Perform the steps to search for and open a Parent Incident, Request, or Change Order ticket as
outlined in the Searching section of this document.
2) Ensure that the Status of the parent has changed. Select the ‘Parent / Child’ tab.
3) Click [Update Child Status] then [Search]. Children of the parent will list in the recipient list.
56
Attachments
Most files can be attached to an Incident, Request or Change Order in SDM. If the attached
document is viewable through your web browser, it will open automatically in that browser. If it
cannot be viewed this way, you will be prompted to save the file locally.
Document Attachments
URL Attachments
Viewing Attachments
Document Attachments
1)
Perform the steps to create a ticket as outlined in the Creating Incidents, Creating Requests, or
Creating Change Orders sections of this document but do not click the [Save] button.
2) Select the ‘Additional Information’ main tab. Select the ‘Attachments’ sub tab.
3) Click the [Attach Document] button.
4)
57
Click the [Browse] button.
5) Browse to the location of the file. Double click the file to attach.
6) Enter a Name and Description into the respective text boxes.
7) Click the [Upload] button to insert the file.
8) If the file has uploaded successfully, you will receive a confirmation dialog box. Select OK to
return to the ticket.
9) Select the [Save] button to finish creating the ticket.
URL Attachments
1) Perform the steps to create a ticket as outlined in the Creating Incidents, Creating Requests, or
Creating Change Orders section of this document but do not click the [Save] button.
2) Select the Attachments tab.
3) Click the [Attach URL] button.
4) Enter the fully qualified URL of the desired website into the URL textbox. Include the
appropriate http:// or https:// markup before the resource name.
58
5) Enter a Name and Description into their respective text boxes.
6) Click the [Save] button.
7) Click the “Close Window” link to return to the ticket.
8) Click the [Save] button to finish creating the ticket.
Note: Attaching a URL only provides a link to the specified site. No content from the site is saved
within SDM.
Viewing Attachments
1) Perform the steps to search for and open an Incident, Request, or Change Order ticket as
outlined in the Searching section of this document.
2) Click the Attachments tab to display documents and URLs attached to the ticket.
3) To view a document or URL, click on the corresponding link on the Document column
59
60
Application Customization
Scoreboard
Personalized Responses
Scoreboard
The Scoreboard is an interface available on the left hand pane of the main SDM screen that is
used to display the number of incidents, requests, change orders, callbacks, knowledge
documents, and tasks assigned for the logged in analyst and their group(s). Also visible are
the enterprise counts for assigned and unassigned incidents, requests and change orders.
Each Scoreboard entry represents a query against the data in the SDM database. There are
numerous pre-built queries available to add to the Scoreboard. Additionally, custom
Scoreboard queries can be created by the SDM Administration team for use on the
Scoreboard.
Viewing Results
Update Counts
Modifying Folders and Queries
61
Viewing Results
To view a list of the results of any of the categories displayed in the Scoreboard, click the
category, and a summary of the items in that category appears in the right hand list area.
Update Counts
To update the counts that are currently displayed in the scoreboard, click the [Update
Counts] button. Scoreboard counts will refresh regardless every five minutes.
62
Modifying Folders and Queries
The Scoreboard can be customized by adding, moving or deleting queries and folders.
Accessing the Customize Scoreboard Screen
Adding Folders
Nesting Folders
Adding Query Nodes
Renaming Query Nodes
Deleting Items
Accessing the Customize Scoreboard Screen
1) Select ‘Customize Scoreboard’ from the File menu
63
Adding Folders
1)
Access the Customize Scoreboard Screen.
2) The left hand pane of the Customize Scoreboard screen is a representation of the current folder
and query structure of the Scoreboard. Click on an existing folder. The new folder, once
created, will display beneath the folder selected.
3) Enter the folder name into the ‘Folder Label’ textbox. Click the [Add New Folder] button.
64
Note: The New folder will now be displayed on the left hand Scoreboard tree.
4) Click the [Finished] button for the changes to take effect.
Nesting Folders
Scoreboard folders can be nested within existing folders to help with categorizing queries.
1) Access the Customize Scoreboard Screen.
2) Click on the plus sign next to an existing folder, and then click on the folder itself. The new
folder, once created, will display nested beneath the folder selected.
3) Enter the folder name into the ‘Folder Label’ textbox. Click the [Add New Folder] button.
65
Note: The New folder will now be displayed on the left hand Scoreboard tree.
4)
Click the [Finished] button for the changes to take effect.
Adding Query Nodes
1) Access the Customize Scoreboard Screen.
2) Click the ‘Node’s Stored Query’ field lookup.
66
3) Click the [Search] button from the Stored Query Search screen.
4) Select the query node to add to the Scoreboard from the Stored Query list selection window.
Tip: If the query to add does not exist in the Stored Query List create a request ticket to the SDM
queue to have it added.
67
5) The ‘Node’s Stored Query’ and ‘Node Label’ will populate from the selection. Update the Node
Label field to something more descriptive if necessary.
6) The left hand pane of the Customize Scoreboard screen is a representation of the current folder
and query structure of the Scoreboard. Click on an existing folder. The new query node once
associated will display beneath the folder selected.
68
7)
Click the [Add New Node] button.
Note: The New folder will now be displayed on the left hand Scoreboard tree.
69
8) Click the [Finished] button for the changes to take effect.
Renaming Query Nodes
1) Access the Customize Scoreboard Screen.
2) Select the Query to be renamed from the left hand pane of the Scoreboard Customization
screen.
3)
Rename the Query Node from the ‘Selected Node’s Label’ textbox. Click the [Update Item]
button.
4) Click the [Finished] button for the changes to take effect.
Deleting Items
1) Access the Customize Scoreboard Screen.
2) Select the Query Node or Folder to be deleted from the left hand pane of the Scoreboard
Customization screen. Click the [Delete Selected Item] button.
70
3) Click the [Finished] button for the changes to take effect.
Personalized Responses
Personalized Responses are saved text messages that can be used as, or appended to a ticket’s
closing comments. Personalized Responses are typically used to provide instructions for common
issues and to provide standard greeting or signature blocks. Utilizing Personalized Responses saves
time and provides the Affected End User with consistent, detailed information.
Creating Personalized Responses
Using Personalized Responses
Creating Personalized Responses
1) Select New Personalized Response from the File menu.
2) In the Name field, enter a unique name for the Personalized Response.
Note: Personalized Response names must be unique within SDM. Prefacing your Personalized
Response names with your UW Medicine login will ensure uniqueness.
71
3) In the Response field, enter the text to be included in the Personalized Response. Click the
[Save] button.
Using Personalized Responses
1) Perform the steps to create a ticket as outlined in the Creating Incidents, Creating Requests, or
Creating Change Orders section of this document.
2) Select Update Status from the Activities menu.
3) Select the desired response from the Personalized Response dropdown menu.
4) Click inside the Reason for Status Change box to insert the response. Make any other desired
changes to the ticket and click the [Save] button.
Note: The contents of that response will be populated in the Reason for Status Change box. You may
make further changes to the Reason for Status Change, if necessary.
72
Notifications
Notifications in SDM are used to let a Group, Assignee, or Affected end User know that an event has
occurred. Events that can generate an automatic notification include ticket Open or Reopen,
Transfer, Escalation or De-escalation, and Close. Additionally Analysts can send out a Manual
Notification to inform a contact and to log the action within a ticket. Currently SDM supports
notifications by email or alphanumeric pager.
Notification Methods
Notification Types
Affected End User Notifications
Assignee Notifications
Group Notifications
Manual Notifications
Notification Methods
Notification Methods are mediums in which a notification can be sent when a Notification Type
event has occurred. The Notification Methods in use in SDM are Email, PageOnHigh, and <Empty>.
Email
PageOnHigh
<Empty>
73
Email
Email is the default Notification Method in use on Employee contact records when an Open /
Reopen or Close Notification Type event has been invoked. It is also the default Notification Method
in use on Analyst contact records for the Close Notification Type.
If an Email Notification Method has been configured it will apply on Incidents, Requests and Change
Orders.
In order for an email to be successfully sent to the recipient a valid email address must be listed in
their active SDM contact record.
74
PageOnHigh
The PageOnHigh Notification Method is used to text page the recipient with the ticket details when
an Incident with a Priority of High or Critical has been assigned.
PageOnHigh is the default Notification Method in use on Analyst contact records when an Open /
Reopen, Transfer, or Priority Change Type event has been invoked. If a PageOnHigh Notification
Method has been configured it will apply to Incidents tickets only. Pages will not occur when an
event occurs on a Request or Change Order.
In order for a page to be successfully sent to the recipient a valid Pager Number and Pager Email
Address must be listed in their active SDM contact record.
In addition to the page a supplemental email will be sent to the contact if the contact’s Email
Address is populated with a valid address.
<Empty>
If a Notification Type has been set with the <Empty> Notification Method no event will be triggered.
<Empty> is the default Notification Method in use on Employee contact records when a Transfer or
Priority Change Notification Type event has been invoked.
75
Notification Types
Notification Types are triggers used to initiate a Notification Method when an event on a ticket
occurs. The Notification Types in use in SDM are (On Ticket) Open, Transfer, Priority Change, and
Close.
On Open
On Transfer
Priority Change
On Close
Notification Types are associated to all SDM contacts within the Contact Record screen. Each
Notification Type has an associated Notification Method value. Each value determines how the
individual will be notified when an event has occurred.
On Open
The Notification Method selected for the ‘On Open’ Notification Type is applied when a ticket is
Opened or Reopened.
76
On Transfer
The Notification Method selected for the ‘On Transfer’ Notification Type is applied when a ticket is
transferred to another Group or Assignee.
Priority Change
The Notification Method selected for the ‘Priority Change’ Notification Type is applied when a ticket
is escalated or de-escalated.
On Close
The Notification Method selected for the ‘On Close’ Notification Type is applied when a ticket is
closed.
Affected End User
Notifications are sent to the Affected End User based on their contact record Notification Method
configuration. By default customers are set to receive an email notification when a ticket is Opened
or Reopened, and when a ticket is set to Closed.
An Affected End User will not receive a page on a Notification Event, regardless of their Notification
Method configuration. Paging events are only applicable to Incidents for Groups and Assignees.
Assignee Notifications
Notifications are sent to the Assignee based on their contact record Notification Method
configuration. All Assignees must be granted the Analyst Access Type. By default Analysts are set
to receive an email notification when a ticket is set to Closed and a text page when a High or Critical
Incident is Opened, Reopened, or Transferred. Additionally a text page will be generated when an
Incident ticket is escalated to a High or Critical Priority, or de-escalated from a Critical to a High
Priority.
77
Group Notifications
Notifications are sent to a Group based on its contact record Notification Method configuration. By
default Groups are not set to receive notifications on any ticket event.
Autopage Integration
Group Notify Option
Autopage Integration
If a SDM group has a corresponding group in Autopage the group’s contact record can be configured
to page the group’s oncall. Enter a request ticket to the SDM to make modifications to group
contact records.
1) Verify that the Group’s Notification Methods are configured as required. A typical configuration
for a group notification is PageOnHigh for incident ticket Open or Reopen, Transfer and Priority
Change.
2) Appropriate syntax is <Autopage Group Name> “on call” in the ‘Pager Number’ field (e.g. test on
call).
78
Group Notify Option
Within a Group Contact Record there is an option called the Notify Flag. This option can be turned
on or off for each Group Member. Turning on this flag applies the configured Notification Types for
the group in addition to the Notification Types configured for the Group Member. If a ticket is
created for the group the Analyst is in, even though the analyst is neither the Affected End User nor
Assignee, they will receive the notification as configured in the Group Contact Record. If the ticket
was created for the group and the Analyst was the Affected End User or Assignee they would
receive both notifications. To view Notify settings perform the following steps:
1) Search for and open the Group’s Contact Record.
2) Select the ‘Members, Service Contracts, Auto Assignment’ main tab. Select the ‘Members’ sub
tab. The Notify setting indicates whether the contact is configured for additional notification.
In order to modify Notify access a contact must be assigned the Super Analyst or Administrator
Access Type. Requests for modifications can be made by creating a Request ticket to the SDM
group.
Manual Notifications
A Manual Notification is a function used to send any SDM contact a page or email from within an
existing ticket. The notification history is automatically logged within the ticket Activity tab.
1) Perform the steps to search for and open an Incident, Request, or Change Order ticket as
outlined in the Searching section of this document.
79
2) Select ‘Manual Notify’ from the Activities menu.
3) Select an available recipient from the list, or select the ‘Contact’ lookup to search from the list of
all SDM contacts. Click the [Add Recipients] button. The contact will now display under the
‘Selected Recipients’ section.
Note: Multiple individuals can be notified by selecting the ‘Contact’ lookup and repeating step 3.
4)
Select the Notification Method from the corresponding dropdown box. Available options are
Email and PageOnHigh. Selecting Email with notify the recipients regardless of the Priority.
Selecting PageOnHigh will both page and email the recipients regardless of the ticket Priority.
Note: In order for a notification to be successfully sent the recipient’s contact record must be
populated with a correct email, pager and pager email address.
5)
Select the Internal checkbox if you want the logs on the ticket’s Activities tab to only be
available to SDM Analysts or Administrators.
6) Update the Message Title and/or Message Text if applicable. Click the [Notify] button.
80
Glossary
Access Type
Indicates the system access level assigned to a contact. Access types can be set to Administrator,
Analyst, Knowledge Engineer, Knowledge Manager, Employee, or Super Analyst.
Affected End User
Specifies the contact name of the person affected by the Change Order. Stores current affected
contact information in the ticket for use in reporting. Values can be entered directly or by clicking
the magnifier to search for the name.
Assignee
Specifies the name of the person assigned to handle the change order. Values can be entered
directly or by clicking the magnifier to search for the name.
Assignee Group
‘Assignee Group’ specifies the name of the group that is responsible for implementing the Change
Order. Any individual contact assigned to the group can handle the record after it has been assigned
to the group. Values can be entered directly or by clicking the magnifier to search for the name.
Authorized Approver
‘Authorized Approver’ is located on the ‘Plans’ tab of Change Orders and specifies the name of the
person with appropriate authority that has approved a UW Medicine express or emergency Change
Order.
Backout Plan
‘Backout Plan’ is a text control on the ‘Plans’ tab of Change Order tickets. Backout Plan is a required
field for Routine Change Orders and at a high level should articulate how an unsuccessfully deployed
change would be backed out so as to return the service or configuration item to a state before the
change.
CAB
The ‘CAB’ field specifies the group that is responsible for reviewing requests for changes (RFCs). The
CAB provides multiple perspectives necessary to ensure proper decision making about
implementing changes. The CAB can include members from the application team, development
manager, component owner, QA, support, and any additional parties deemed necessary. Values can
be entered directly or by clicking the magnifier to search for the name.
81
Category
Indicates the general category of the change within your IT environment (for example, CC Routine).
Change categories provide default values that are entered automatically on all change orders
assigned to the category. Values can be entered directly or by clicking the magnifier to search for
the name. Most Change Order categories create a set of custom questions known as properties
which display on the ‘Properties’ tab of a change order when in a create, edit, or view screen.
Change Order
Change Orders are the addition, modification or removal of authorized, planned or supported
service or service component and its associated documentation.
Data Partition
Data partitions are subsets of the database with restricted access to data records, based on their
content.
Event Duration
Indicates the amount of time required to implement the change in hours and minutes.
External System Ticket
‘External System Ticket’ specifies an identifier for a ticket that belongs to an external application.
This field stores hyperlinks and displays functional links in read-only mode.
Impact
Specifies an impact code, such as ‘1. Enterprise’, that indicates how a change order affects work
being performed. For example, a ticket that requires a network outage for several hours would have
a higher impact than a ticket that takes a printer off-line.
Implementation Plan
‘Implementation Plan’ is a text control on the ‘Plans’ tab of Change Order tickets. Implementation
Plan is a required field for Routine and Express Change Orders and at a high level should articulate
how the change will be incorporated into the production environment.
Need By Date
‘Need By Date’ displays the date that the change order needs to be completed by. Dates are
entered in mm/dd/yyyy hh:mm am | pm format, or by clicking the calendar icon to select a date.
Notification Method
Notification Methods are mediums in which a notification can be sent when a Notification Type
event has occurred. The Notification Methods in use in SDM are Email, PageOnAll, PageOnHigh, and
<Empty>.
82
Notification Type
Notification Types are triggers used to initiate a Notification Method when an event on a ticket
occurs. The Notification Types in use in SDM are (On Ticket) Open, Transfer, Priority Change, and
Close.
Incident
An incident is an event which is not part of the standard operation of a service and which causes or
may cause disruption to or a reduction in the quality of services and customer productivity.
Incidents are considered Break / Fix events.
Priority
Specifies the priority ranking of the record to determine the amount of attention it receives. The
SDM priority levels are ‘1. Critical’ (highest) through ‘5. Normal’ (lowest).
Request
Requests are petitions for new functionality. Requests are made for an increase of existing
functionality and are not used for Break / Fix events.
Requested Date
Specifies the start date and time a change order appears on the Change Calendar pages. This field is
optional, though must be filled out in order to be reviewed by the Enterprise Change Control board.
‘Requested Date’ must contain a date value if the Schedule Duration field contains a date value.
Changes without an implementation date do not appear on the Change Calendar tab.
Requester
‘Requester’ specifies the name of the person who initiated the ticket. This person must be a defined
contact. Values can be entered directly or by clicking the magnifier to search for the name.
Requester Group
‘Requester Group’ specifies the group name associated with the initiated ticket. This group name
must be a defined contact. Values can be entered directly or by clicking the magnifier to search for
the name.
Risk
Identifies the risk level associated with the change order.
Scoreboard
The Scoreboard is an interface available on the left hand pane of the main SDM screen that is
used to display the number of incidents, requests, change orders, callbacks, knowledge
documents, and tasks assigned for the logged in analyst and their group(s). Also visible are
the enterprise counts for assigned and unassigned incidents, requests and change orders.
83
SLT
An SLT is a formally negotiated target for response times based on the service and priority between
two parties. It is a contract that exists between customers and their service provider, or between
service providers. It records the common understanding about services, priorities, responsibilities,
guarantee, and such—collectively, the level of service.
Status
Specifies the status code of the record. For example, tickets can be listed with a status code of
Deferred or Closed. Values can be entered directly or by clicking the magnifier to search for a
status. The blue button (on the left side of the Status field) lets an analyst change the current status
to the next default status.
Type
Specifies the ITIL change type as Routine, Express, or Emergency. A default value may be defined
based on the selected change category.
84
Appendix A: Keyboard Shortcuts
Tab
Focuses on the next field Initiates auto fill for a lookup field.
Shift + Tab
Focuses on the previous field. Initiates auto fill for a lookup field.
Alt+Up
Arrow
On a detail form of search filter, focuses on the header of the current field if a
hyperlink. If not a hyperlink it focuses on the field above the current field.
Alt+Down
Arrow
On a detail or search filter, focuses on the field below the current field.
Right Arrow
On a hyperlink with a context menu, displays the context menu.
Left Arrow
In a context menu, closes the menu.
Shift+PageU
p
Focuses on the first field of a form. When used in the scoreboard, shifts the
focus to the main form.
Shift+Home
Same as Shift+PageUp except in a text entry box where it will select all text
from the cursor to the beginning of the line.
Shift+Page
Down
Focuses on the last field of the form. If the focus in on the last item in a filter
of edit in list form and list is displayed, shifts the focus to the last item in the
list .Scroll through topics in a list.
Shift + End
Works the same as Shift+Page Down except in a test entry box, where it will
select all text from the cursor to the end of the line.
Alt+x
Focuses on the scoreboard.
Alt+Letter
Activates the button or menu with the underlined letter.
Alt
+Number
Shows the notebook tab with the underlined number and focuses on its first
field.
Alt+g
Focuses on the Go button input field.
85