Functional/Technical HUIT_Functional_TechSpec_v11a.docx March 8, 2013 Version 11.0 Page 1
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 Page 2
Table of Contents Introduction... 4 Functional Design Scope... 4 Application... 4 Screen Design & Field s... 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... 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 Page 3
Introduction This Functional and Technical 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 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 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 is intended to establish a standard 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 process across HUIT. Some features of the application (such as task records for ) will be provided after a standard process has been achieved. Application HUIT s process is described in the Process Description. The HUIT application for 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 s 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 Page 4
Management o o o o Stuff I need to pick up (Unassigned to my group) Tickets by Group Breached tickets by group Major Incidents / High Priority by group Header Welcome:[ROLENAME] Naviga on ContentBlock Breached Tickets by Group ContentBlock ContentBlock Major Incidents/High Priority by Group ContentBlock ContentBlock ContentBlock Tickets by Group Footer 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 o o o What each person is doing What is in my queue My groups oldest tickets 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. Page 5
Header Welcome:[ROLENAME] Naviga on ContentBlock ContentBlock Area 1 ContentBlock ContentBlock ContentBlock ContentBlock Area 2 Area 3 Footer The HUIT branding guidelines are located here: Figure 1 Style Guideline http://isites.harvard.edu/fs/docs/icb.topic937886.files///huit%20guidelines%207 25 11.pdf Page 6
Service desk rep (First Line) Figure 2 illustrates the home page for 1 st 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.) Welcome:[ROLENAME] Contact Self Service ServiceDesk Incident u Problem Change Reports Config ra on ServiceCatalog Reports BSMMap SocialIT MyWork MyGroupsWork News ITILSummary Counts Cri calitems OverdueItems ItemsOpened> 1Week OpenItemsby Escala ongraph Figure 2 1st Tier & Service Desk Home Page Area 1 Navigation Content Block Field Name Description Dropdown to navigate to Incident screens Create New Assigned to me My Groups Work Open Page 7
Open Unassigned Resolved Closed All Reports My Work 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 popup 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 1 st 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). Page 8
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 Additional Fields: Incident/Request Incidents by Same Contact Symptom/Operation Incidents by Same Category Related Incidents Incident Block FIELDS Required Field Name Description Type Open Close Incident Number Auto generated number. Default mask is String Y Y Number Short Description Text Text Y Y Dropdown to navigate to Incident screens Reference Y Y Contact Includes all the user contact information Reference Y Y (including HUID). Auto filled to the extent possible. Also store alternate contact info. Renamed from Caller. Configuration Item Optional field. Light weight way to handle Reference N N HUIT Remedy Product fields Incident / Request Drop down to select type of ticket (default is Reference Y Y Incident) If Request, transfer to Request screen. Service Category Separate line on the Incident form. Re named from Category. Reference Y Y Page 9
Service Drop down / search, options depend on the Reference Y Y service category selected. Separate line on the Incident form. Re named from sub category. Symptom / Operation Drop down, options depend on whether it is Reference Y Y 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. Impact Drop down, default to 4 Individual Reference Y Y Urgency Drop down, default to 2 Work degraded Reference Y Y Priority Opened by Contact Type (Calculated from impact and urgency see the Priority Matrix in Process Description); if VIP, raise Priority by a factor of 1. Auto filled based on login profile of person entering the ticket Drop down choices: Phone Email Portal Direct Entry (walk in) Reference Y Y Reference Y Y 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 Assigned To Related Incidents Incidents by same contact Incidents by same category Table 3 Incident Block Fields Screen Icons and Controls: If not resolved by first line group, the default is based on category / service / symptom Y Y Name of individual that the Incident is Y Y assigned to Related incidents are not kept in sync. Should N N be able to select closed incidents. List field of Incidents by same contact N N List field of Incidents by same category N N Page 10
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 Field Name Description Type Open Close Customer Watch List IT Watch List Comments for Customer Multiple people that are automatically informed of activity on the ticket; default field mask is Watch List Multiple people that are automatically informed of work notes associated with the ticket; default field mask is Work notes list 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 Icon N N Icon N N Text N N Page 11
(Customer visible) Table 5 Notes Block Fields Figure 8 illustrates the Work notes Block ADD: Sensitive Notes Field Figure 5 Work notes Work notes Block FIELDS Required Field Name Description Type Open Close 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 First Line opportunity notes Checkbox Checkbox N N 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 Field Name Description Type Open Close Knowledge FIELD WILL BE HIDDEN Checkbox N N Closed by Auto fill based on login of person closing the Reference N Y ticket. 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 Page 12
Table 7 Closure information Block Fields Resolved for more than 5 business days 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 Field Name Description Type Open Close 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. Page 13
Functional and Technical Revision: 11.0 Revision Date: 03/08/2013 Release Date: 2/28/2013 Author: John Worthington Status Diagram New 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. Open Statuses Unassigned 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. On Hold Statuses (SLO clock is stopped) Status automatically set to Assigned when user updates replies in Portal or via Email. Status automatically set to Assigned when the Assignment To field is changed. On-Hold Waiting for User On-Hold Waiting for Approval Assigned Status can only be changed to Resolved if all tasks are Closed. On-Hold Waiting for Vendor Resolved After 5 Business Days Status automatically set to Closed after 24 business hours. Closed Cancelled Figure 9 Status Diagram Page 14
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 ithelp@harvard.edu http://huit.harvard.edu Page 15
Figure 10 Current Confirmation email Assigned to a group email From: HUIT Support Center <ithelp@harvard.edu> 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 <ithelp@harvard.edu> [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] Summary: [Short Description] Name: [Assigned To] Location: [Assigned to Location?] [LINK?] https://remedy.fas.harvard.edu/arsys/forms/fasit remars.fas.harvard.edu/hpd%3ahelp+desk/?qual='case%20id*%2b'%3d%22inc000000556194%22 (Example) Notes: [Comments FROM User?] Page 16
Assigned to an individual email From: HUIT Support Center <ithelp@harvard.edu> 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 <ithelp@harvard.edu> [Incident Number] (Incident Number will be a hyperlink to the Incident) has been assigned to you. Service Type: [Incident/Request] Priority: [Priority] Summary: [Short Description] Name: [Assigned To] Location: [Location?] [LINK?] https://remedy.fas.harvard.edu/arsys/forms/fasit remars.fas.harvard.edu/hpd%3ahelp+desk/?qual='case%20id*%2b'%3d%22inc000000556194%22 (Example) Notes: [Comments FROM User?] Page 17
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 ithelp@harvard.edu 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 ithelp@harvard.edu http://huit.harvard.edu Was this helpful? Survey Link: https://remedy.fas.harvard.edu/arsys/shared/followupsurvey.jsp Page 18
Figure 11 Current Resolution email Page 19
Survey Questions Survey Link: https://remedy.fas.harvard.edu/arsys/shared/followupsurvey.jsp Page 20
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. 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 closed on first call Total All Services Total Incidents per period % of total Incidents per period closed on first call Page 21
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 Change to Service Figure 12 Incident Backlog (Number of Incidents by Service) Page 22
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 period closed on first call Total All Services Total Major Incidents per period % of total Major Incidents per period closed on first call 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 assignment target # Incidents & % of resolution target 1 Major Incidents Total Incidents # Incidents & % of # Incidents & % of Page 23
assignment target resolution target 2 High Total Incidents 3 Moderate Total Incidents 4 Normal Total Incidents # Incidents & % of assignment target # Incidents & % of assignment target # Incidents & % of assignment target # Incidents & % of resolution target # Incidents & % of resolution target # Incidents & % of resolution target Desktop Incidents Priority Total Incidents # Incidents & % of assignment target # Incidents & % of resolution target 1 Major Incidents Total Incidents 2 High Total Incidents 3 Moderate Total Incidents 4 Normal Total Incidents # Incidents & % of assignment target # Incidents & % of assignment target # Incidents & % of assignment target # Incidents & % of assignment target # Incidents & % of resolution target # Incidents & % of resolution target # Incidents & % of resolution target # Incidents & % of resolution target Page 24
Report Title: Assignment Accuracy Number and percentage of Incidents incorrectly assigned (re assigned at least 3 times) Change to Service Page 25
Report Title: Categorization Accuracy Number and percentage of Incidents incorrectly categorized Change to Service 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] Page 26
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 High Medium Normal Urgent High Medium 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) Page 27
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 thankyou response). Page 28
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). Batch Loaded 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 Page 29
Primary email Work Email 2 Personal Email 3 Alt 1 Email 4 Alt 2 Email 5 Alt 3 Instead of 'primary', 'secondary' can we identify as Work Phone 'work', 'mobile', 'home', 'lab', etc.? Ext Mobile Phone Home Phone Lab Phone Other Phone Department No. Department Name Primary Location Address Primary Room No. Alternate Contact Name Alternate Contact Phone Alternate Contact Email Table 10 Customer Record Data Fields X X X X X Authentication Single Sign on 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 Page 30
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. Page 31
The following information is specific to functionality that will be available after the June release. Employee Self Service (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, 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 Self Service Portal Figure 5 illustrates the home page for the Self Service Portal. Page 32
Welcome:[ROLENAME] Self Service Search News QuickLinks FAQ 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 Page 33
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 Field Name Description Type Open Close Task Number Auto generated number. Default mask is String Y Y Number Short Description Text Text Y Y Requested Item Not Used Due Date The date the user would like the request Date N N fulfilled Approval Not used State Not used Reference Y Y Parent Displays the Incident number of the ticket Reference N N the task relates to; auto filled by the system Requested for Name of person that wants the request Text Y Y Page 34
Assignment Group Assigned To IT Watch List Additional comments fulfilled If not resolved by first line group, the default is based on category / service / symptom Name of individual that the Incident is assigned to Multiple people that are automatically informed of work notes associated with the ticket; default field mask is Work notes list Text box for adding additional instructions as required Y Y Y Y Icon N N 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 Field Name Description Type Open Close Requestor Name of person requesting service; (has a lookup button); field mask is Open on Reference Y N Page 35
Previous incident? behalf of this user 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. Page 36