Incident Management Training Outline Incident Management Overview Incident Management Lifecycle Document Details Investigate and Diagnose Resolve and Close

The Incident Lifecycle 

Incident Definition Incident Management Incident Management Something is broken Something is about to break Incident Management Restore service ASAP Minimize business disruption Description: An Incident is an unplanned interruption or a reduction in the quality of an IT service or a failure of a configuration item (CI) not yet impacting an IT service. Incidents can include failures or service degradation. Goal of Incident Management: Restore normal service operation as quickly as possible with minimum disruption to the business, thus ensuring the best achievable levels of availability and service quality are maintained.

ServiceNow IT Service Management Submit Incidents, review status Self-Service Request goods and services Service Catalog Customer Permanent Fix Investigate Root Cause Fix/Resolve Known Root Cause IT Process Incident Management Problem Change Management Configuration Management Database Configuration Management Knowledge Base Knowledge Management Notifications, workflows, integrations ServiceNow Platform IT Service Management (ITSM) is an integrated process that enables an IT organization to deliver services that meet business requirements. ServiceNow provides an integrated comprehensive ITSM solution built on best practices including ITIL. The diagram describes the typical process and data flow through the system. Typically a customer/end-user initiates a support issue (Incident) or a request for goods or services through the Service Catalog, located in the Self-Service Application or a user-friendly Employee Self-Service (ESS) Portal. An Incident may then either result in a Change Request or a Problem investigation depending on the status of root cause identification. Once a Problem is initiated, a root cause analysis may yield an identified permanent fix in the environment, resulting in the initiation of a Change Request. Certain Requests made from the Service Catalog may also result in a Change Request, which initiates the proper tasks to fulfill the request. Incidents, Problems, Changes, and Requests are linked to affected Configuration Items (CIs), located within a repository called the Configuration Management Database (CMDB). Information about these processes, CIs, best practices, and more is documented in the Knowledge Base, maintained and accessed directly in ServiceNow. Knowledge Base articles may be used internally by IT users or shared directly with the customer to restore service and answer inquiries. Foundation

Relationship to other Processes Incident Management Request Management Request Management: Some Requests may be misclassified as a Incidents, and vice versa: An Incident is “something’s broken” or “I need help,” whereas a Request is “I need something.”

Incident Process Overview Document Details Log Incident details Prioritize and categorize Assign or escalate Investigate and Diagnose Locate Assignment Research Incident Identify cause/workaround Apply known resolution Resolve and Close Restore service Update documentation Customer validation Automatic Incident closure

Investigate and Diagnose Incident States Document Details Investigate and Diagnose Resolve and Close New The initial State of an Incident when first created is New but become Active when record is saved Assigned When an Incident is assigned to an individual, the State is changed to Assigned by the system Resolved Once service is restored, the Incident State is set to Resolved The Incident is Closed automatically by the system 3 business days after resolution, unless the Incident is reopened Depicted is the normal State progression through the Incident Process. However, not every State has to progress in this sequence. The State may progress forwards or backwards through the lifecycle as the Incident progress dictates with one exception: Incidents cannot be reopened after they reach the Closed state. There may be additional Awaiting States automatically or manually selected during the Incident lifecycle, including: Work in Progress- when incident is being worked on Awaiting User Info – waiting for Caller to provide information Awaiting Vendor– waiting for Vendor to provide information An email is sent to the Caller upon Incident submission, when Additional Comments are updated, and when the Incident is set to the Resolved or a Awaiting States. Additional awaiting states may be used at any time in process

Overview Module 1 4 2 3 The Overview Module (Incident > Overview) provides a dashboard of Incident indicators. Use the plus icon to add additional or new content and customize your Overview. This action personalizes the Overview module for you only and is remembered next time you log in. Click and drag any box in the Content Frame to rearrange reports and gauges on your Incident Overview page. Hover at the top right of any box in the Content Frame to view additional options, including Edit, Refresh, Widget Appearance, and Close. Actions at the top right of the Incident Overview page include a Refresh and Refresh Interval option. Additionally, the Change Layout option allows you to graphically redesign the appearance of your Overview page.

The Incident Application Incident Management takes place in the Incident Application within the Application Navigator You can also access Incidents via certain Modules in the Self-Service and Service Desk Applications Incidents opened on your behalf List of all Active Incidents Creation and management of Incident records The Incident Application contains multiple Modules used in Incident Management: Record Creation Create New - Opens a new incident form Lists Assigned to me - Opens list of Incidents assigned to the logged-in user Open - Opens a list of all active Incidents Open – Unassigned—Opens a list of unassigned incidents Resolved - Opens a list of Incidents in a resolved state Closed - Opens a list of all closed Incidents All - Opens a list of all Incidents regardless of state Visual Tools Overview - Combination of different types of content designed to provide the Incident Management personnel relevant information Critical Incidents Map - Uses Google map functionality to display geographic location of the organization’s critical Incidents Graphical views of Incident records

The Incident Lifecycle ✔ 

Identify and Classify The first activity in the Incident Management process is to identify and classify the newly detected/reported Incident Steps: Launch a new Incident record Capture initial information Caller Details Category Priority

Report a New Incident New Incident Self-service portal Phone Email Chat Walkup Monitoring Tool Incidents may be reported either electronically or manually. Electronic submission of an Incident: Self-service (Phase 2 of Project) Manual submission of an Incident: Chat – (Phase 2 of Project) Phone Call Walkup

Launch a New Incident Methods of launching a new Incident record include: Incident Application Incident > Create New Incident List Any Incident List > New Fulfillers can launch new Incident records from several places: From the Application Navigator, select the Create New Module

New Incident Form A new and empty Incident form loads. A small number of read-only fields are automatically prepopulated with values such as Number and Opened. Other fields, such as Contact Type and State contain a default value but can be edited throughout the lifecycle of the Incident. An asterisk to the left of a field label indicates that the field is mandatory: The asterisk is red when the field is empty and requires entry Becomes light-red after it is filled with a value Once the record is saved, the asterisk will show in black Note: There may be mandatory fields on other tabs, such as the Notes tab, as well. Read-only fields Default values (Editable) Mandatory fields

Caller The Caller is the person reporting the Incident Type Caller name to select from list of values Click search glass icon to browse User list Caller is a mandatory field to select the person who is reporting the Incident. The Caller may be experiencing the issue or reporting the Incident on behalf of another user. The Caller field is a Reference field, meaning that you must select a predefined value from a different table; in this case, the User table, containing the names of all available users. To populate this Reference field, you can simply begin typing the Caller’s name and select the appropriate value from the dropdown list. Use an * (asterisk, “contains” search) if you are not sure of the exact value. Additionally, you can browse the User list by clicking on the search glass to the right of the Caller field. Click the search glass to open individual column search fields, where you can search on any available User field. Like all Reference fields, the Caller field turns red to indicate an Invalid Reference. Ensure that you have selected a Caller from the User list. An accepted Reference value field remains white and the mandatory asterisk indicator to the left of the field turns light red.

Show Related Incidents Caller Icons Once Caller field is populated, additional icons appear 1 2 1 Show Related Incidents 2 Reference Icon Additional icons appear to the right of the Caller field once a value is selected: 1. Show Related incidents - Displays the Caller’s Incident history, including Active and Closed Incidents. Useful for determining duplicate Incidents or informing the Incident Management investigation. 2. Reference icon - Hover over the icon to view a popup of the referenced record in read-only format. When moving away from the record, the display disappears. To keep the popup in view, hold down the shift key before you hover over and move the mouse away. Click the “X” in the top right corner to close the pop-up. You may be able to modify the User record from this view based on your permissions.

Caller Details Once Caller field is populated, additional information may populate based on User record A VIP icon is displayed and the font color turns red to visually identify the organization’s executives The Contact Number field may autopopulate but can be manually edited from other selections within the referenced table Certain users are designated as VIP users and appear in red for high visibility. A Caller’s VIP status may affect the Incident Priority, either automatically in the system or manually, according to best practices. Once a user is entered in the Caller field, additional fields such as Contact Number are autopopulated. These fields can be manually edited if necessary; however, this does not change the underlying values on the User record.

Categorize Category and Subcategory detail the type of Incident Subcategory lists are dependent on the value selected in the Category field Assigning Categories and Subcategories to Incidents can greatly improve the clarity and granularity of report data. It can also assist in the future when investigating similar incidents in the search for a resolution.

Prioritize: Impact and Urgency Priority is read-only and calculated by values selected in the Impact and Urgency fields Priority advises the Service Desk how quickly they should address the Incident Priority Matrix Urgency 1 Urgency 2 Urgency 3 Impact 1 Priority 1 Priority 2 Priority 3 Impact 2 Priority 4 Impact 3 Priority 5 Incident prioritization typically drives the timeframes associated with the handling of the Incident and the targeted time to resolution. ITIL suggests that Priority be made dependent on Impact and Urgency, where: Impact is what will happen if the issue is not addressed and typically includes a measurement of both scope (number of users impacted) and operations (the extent to which core business functions are impacted or the risk of the potential loss of mission critical data). Urgency is a measure of business criticality of an Incident where there is an effect upon business deadlines. The urgency reflects the time available to restore service before the impact is felt by the business.

Incident Details Summarize the Incident details in the Short description and Description 1 1 Suggestion Provide a brief summary of the issue in the Short Description and Description field. A icon appears to the right of the Short Description field: Suggestion - The light bulb icon provides a list of common issues you can select as a value in the Short Description field.

Audit Fields Incident history tracked in read-only fields: Opened autofills with date/time Incident was opened Opened by autofills with user who opened the Incident Fields cannot be modified by fulfillers Certain fields on the Incident form are read-only and autopopulated based on system information. For example, the Opened and Opened by fields are automatically filled with the logged-in user’s name and the date/time the new Incident record was opened. If the Incident was created by the end user via the Self-Service portal, that information is automatically included in the Incident form when accessed via the Incident Application.

Contact Type Use the Contact Type dropdown list to select how the Incident was reported Default value on new Incident is Phone Default value on Incidents created via Self-Service module is Self-service The Contact Type field presents dropdown menu options to indicate how the Incident was reported. The default value on a new Incident created in the Incident Application is Phone. The default value on a new Incident created from the Employee Self-Service Portal is Self-service. Fulfillers can modify this value.

Incident State The State field tracks the lifecycle stage of the Incident Can be manually and/or automatically updated throughout the Incident Management process State When Used New Any new Incident submission Assigned Automatically upon Assigned to user Work in Progress When incident is being worked on Awaiting User Info Pause Incident investigation while awaiting customer information Awaiting Vendor Pause Incident investigation while awaiting vendor information Resolved Service has been restored; awaiting customer confirmation or auto-closure The State field tracks the lifecycle of the Incident and is critical to reporting and Service Level Agreements (SLAs), discussed in detail in the Investigate and Diagnose section of this training. The State value may be selected automatically by the system or manually by the user, depending on the State. Typically, an email notification is sent to the Caller whenever the Incident State is updated.

Assignment Assignment Group may autofill based on other fields You can edit this field or manually enter data If re-routing to another group, leave Assigned to blank Assignment group receives email notification of unassigned task Assignment group designates individual Assignee Or enter Assigned to individual if known Assignee receives email notification of task The Assignment Group value may populate automatically; however, you can enter a new value or edit the existing value. The Assignment group is generally responsible for assigning an individual to the Incident. Upon group assignment, the group receive an email alert notifying them of an unassigned task; a group member follows the email link to make the individual assignment. Alternately, the Assigned to value can also be entered at this point, if known. Both the Assignment Group and Assigned to fields are Reference fields, meaning you must select from a pre-defined list of Groups and Users. Making a selection in the Assignment Group field narrows down the available values in the Assigned to field to only those users who are a member of the selected group.

Additional Comments Use Additional Comments (in the Notes tab) to communicate with the Caller Emailed directly to the customer upon update Should be non-technical and professional Notify additional users of updates to Additional Comments by adding them to the Watch list Inform the customer of timelines and progress Request more information to investigate the Incident Update customer throughout the lifecycle of the Incident You can communicate back and forth with the Caller and other stakeholders directly in ServiceNow using the Additional Comments (Customer visible) field in the Notes tab. Use this field to keep the customer apprised of your work on the Incident or request additional information. Text entered in the Additional Comments field is automatically emailed to the Caller (based on the email address in their User record) upon Save. You can also notify additional stakeholders by adding names and email addresses to the Watch list field, found just above the Additional Comments field in the Notes tab. When the Caller receives an email notification containing Additional Comments, they can respond directly to the email and their feedback will be documented in the Activity log of the Incident record, along with your Additional Comments. To add users to the Watch list, click the lock icon to expand the field and use the Reference field to add names, similar to adding a Caller. Lock the field for a cleaner look on your form.

Work Notes Use the Work notes (in the Notes tab) to provide more detailed information about the Incident Aimed towards an internal, technical audience Not viewable by customer Notify additional (internal) users of updates to Work Notes by adding them to the Work notes list What is the issue? What actions have been taken to reproduce the Incident? Is a Workaround known? What steps have been taken to restore service? The Work notes field provides a journal to document all the technical and behind-the-scenes work on an Incident. Upon Save, Work notes are stored in the Incident Activity section, where they can be viewed and built on by Fulfillers working on this Incident. Fully documenting Work notes is beneficial for Knowledge Management and critical for continuity in the Incident Management process. Work notes are only visible to IT Fulfillers and are not available to external users or customers. Upon Save, Work notes are emailed to the Assigned to user of the Incident. You can notify additional stakeholders by adding names and email addresses to the Work notes list field, located in the Notes tab. To add users to the Work notes list, simply click the lock icon to expand the field and use the Reference field to add names, similarly to adding a Caller. Lock the field p for a cleaner look on your form.

The Incident Lifecycle ✔ ✔ 

Investigate And Diagnose The next activity in the Incident Management process is to investigate and diagnose the Incident Steps: Locate your assignments Establish Parent/Child relationships, if appropriate Review Service Level Agreements Investigate related records Apply a known resolution Reassign/Escalate, if necessary Update the Incident Record

Locate Unassigned Incidents Locate unassigned Incidents in two places: Incident > Unassigned Assigned to field is empty, regardless of Assignment Group Service Desk > My Groups Work Assigned to field is empty; your Group is the Assignment Group It is important to quickly identify unassigned Incidents to ensure that a specific individual is accountable for resolving the Incident with no lapse in response time. You can locate unassigned Incidents in two places: Open – Unassigned - Located within the Incident Application, this Module displays all open Incidents where the Assigned to field is blank, regardless of Group assignment. My Groups Work - Located within the Service Desk Application, this Module displays all open tasks, including Incidents, where the Assignment Group is one of your groups AND the Assigned to field is blank. To quickly identify Incidents within the My Groups module (which includes multiple types of tasks), Group by Task Type from the Column Control menu. If you belong to multiple groups, Group by Assignment group in the Column Control menu to organize your list by Assignment group.

Locate Incidents Assigned to You Locate Incidents where you are the Assigned to user in several places: Incident > Assigned to me All Active Incidents assigned to you Service Desk > My Work All Active Tasks assigned to you (including Incidents) Directly from Email Link Follow link in assignment email notification There are multiple ways to locate work that is assigned to you in ServiceNow. To locate Incidents where you are the Assigned to user, navigate to Incident > Assigned to me. To locate all work where you are the Assigned to user, including Incidents, navigate to Service Desk > My Work. To quickly locate Incidents, Group by Task Type or search for Incidents in the Go to search bar. You will receive an email notification each time a Task is assigned to you - follow the link directly in the email to access your assigned record.

Parent/Child Incidents Some Incidents may be related to one another via a Parent/Child relationship Add a Parent relationship to a Child in the Parent field under the Related Records tab View Child Incidents from the Child Incidents tab in the related lists section at the bottom of the Parent form Occasionally, Incidents may be related to one another by a Parent/Child relationship. For example, if a server crashes and multiple Incidents flood in about subsequent software outages, the outages could linked as Child Incidents back to the Parent server Incident. One benefit of this relationship is that resolving the Parent Incident automatically resolves all associated Child Incidents. To establish the Parent/Child relationship, locate the Parent field on the Related Records tab of the Child Incident. Use the search glass to find and select the appropriate Parent Incident. You can identify whether an Incident has Child Incidents by locating the Child Incident related list at the bottom of the form.

Search Incidents Locate similar Incidents to identify duplicates, known resolutions, or information to help restore service Incident > All or Incident > Open Search by keywords, Category, and/or CI Open record and browse Activity log/Closure tab The goal of Incident Management is to restore normal service as quickly as possible. Reviewing other similar Incidents may provide more information to the Fulfiller, such as identifying duplicate Incidents or Incidents with the same CI or Category. To browse similar Incidents, begin by opening a list of Incidents, such as all Active Incidents (Incidents > Open) or all Incidents, including Closed records (Incidents > All). Use the column header search or Go to search to enter a specific keyword, Configuration item, Category, or Subcategory. Click the Incident Number to open the record and review the Activity log, Related Records tab, and Closure Information tab, which may contain known resolutions or related Problems/Changes.

Search Known Errors Browse the Known Error database to identify and relate Incidents to Problem records Problem > Known Errors View Workaround field to restore service to customer Add Incident as related record to Problem record Multiple Incidents may be related a pre-existing Known Error within the Problem Application. These Known Errors may be in the process of being fixed with a Change, or they may be left as is; either way, the Problem record contains informative fields such as Description, Close Notes, and Workaround. To view Known Errors, navigate to Problem > Known Error and browse by keyword, Configuration Item, Category, or other relevant fields. Click the Problem Number to open the record. You can also associate related Incidents to existing Problems by using the Edit button within the Incident tab. For more information on linking records, refer to the Problem Management training module.

Reassignment Reassign or escalate the Incident record using the Assignment group field Clear the existing group value and select a new group Reassignment does not affect the SLA The number of reassignments is tracked in the Activity list User performing the activity Date/Time the activity was performed Changed field(s) If the initial Assignment group is not appropriate or you need to escalate the Incident, clear the Assignment group and reassign the Incident. The new group will receive an email notification advising them of the assignment and can navigate to the assigned record in the My Groups Work Module. The number of reassignments is tracked in the Activity section of the form. New value Old value

Update Incident Record Continue to use the Work notes field to document non-public activities Use Additional comments to document public activities Visible to all and included in the email notifications Add users to Watch list and Work notes list What is the issue? What actions have been taken to reproduce the Incident? Is a Workaround known? What steps have been taken to restore service? Inform the customer of timelines and progress Request more information to investigate the Incident Update customer throughout the lifecycle of the Incident Continuing to document the Incident over the course of the Incident Management process is critical for Knowledge Management and effective customer communication. Use Work notes to document non-public activities such as behind-the-scenes work and technical workarounds. Only licensed users will be able to view these comments. Add users to the Work notes list to receive updates to your Work notes. Use Additional comments field to document public activities and communicate with the customer. Add users to the Watch List to receive updates to your Additional Comments. The information saved in the Additional comments is included in email notifications to the caller, assignee and anyone on the watch list. Updates made using anyone of these listed methods are saved in the record’s Activity log for a complete audit trail.

Additional Documentation Two methods to add supporting documentation: 1 2 Attach additional documentation such as emails, screenshots, documents, and spreadsheets to your Incident by clicking the Paperclip icon in the form Title Bar. Alternatively, you can simply drag and drop documents from your desktop onto the Incident form. NOTE: The drag and drop feature only works in Firefox 3.6 or later and in Chrome. Support will be added for other web browsers as they implement the HTML5 specification.

Activity List The Activity list displays a log of all updates made to the Incident record from the moment it is launched Click the icon to display a filter allowing you to select which of the available fields to show Collapse, expand, and toggle the Activity log using the , , and icons Use the Activity list as an expandable/collapsible audit trail of everything that happens in an Incident record from open to close. Find details such as what happened, when it happened, and who did it.

The Incident Lifecycle ✔ ✔ ✔ 

Resolve and Close The next activity in the Incident Management process is to resolve the Incident, followed by automatic closure Steps: Validate Incident details Ensure updated documentation Implement resolution to restore service Resolution confirmation email sent Confirm resolution

Final Steps before Closure Ensure the Category, Impact and Urgency are still appropriate to the Incident Example: What started out as an Outlook issue reported by one person might need to be re-categorized as an Exchange outage experienced by multiple users Ensure all Incident documentation is updated, including Additional comments, Work notes, and Attachments Ensure any Related Records are linked to the Incident Accurate documentation of the Incident details is critical for reporting, trend analysis, and Knowledge Management. Any changes you make to the Incident form, along with the original field values, are documented in the form Activity log.

Implement Resolution Once service is restored, update the Incident State to Resolved New fields become Mandatory: Close notes (Closure Information tab) Close code (Closure Information tab) Manually select Resolved State Click the Resolve Incident button or change the Incident State to Resolved when service has been restored for the Caller. Once the Incident State has been set to Resolved, additional fields become Mandatory before Save, including the Close code and Close notes on the Closure Information tab.

Document Resolution Closure Information 3 1 2 Once the Incident State is set to Resolved, fill out additional Resolution details: Select the appropriate Close code - for example, did you restore service via a permanent fix or a temporary workaround? This field is useful for reporting purposes. Enter Close notes. These are beneficial for Knowledge Management, particularly if you are generating a Knowledge Article. Close notes are for internal use and not sent to the customer. Closed by and Closed fields are read-only and are autofilled by the system upon Incident closure.

Resolution Confirmation Caller is notified via email that the Incident is Resolved If Caller is satisfied, no action required If Caller is not satisfied, they can reopen the Incident by clicking the link within the email notification Caller can add details to the outgoing message before sending Incident is automatically reactivated and the assignee notified The Caller is notified by email when their Incident is set to a Resolved State. If the Caller is satisfied that service has been restored, no further action is required. If the issue has not been fixed, however, the Caller can click the link contained within the email to re-open the Incident. At this point, the Caller can also enter additional details in the outgoing email to provide more information to the Incident assignee. Alternately, fulfillers can also re-open an Incident in ServiceNow while the State is Resolved.

Closure If there is no challenge to the resolved Incident, the State is automatically Closed in 3 business days. Email sent to Caller advising of the State change and Incident record closure Documentation of the email is in the form Activity section Only the Caller can close an Incident that is in a Resolved State. If the Incident is not re-opened within 3 business days, the State automatically moves to Closed. At that point, the Incident is located via Incident > Closed and cannot be re-opened by either the Caller or the fulfiller.

Incident Process Overview Recap Document Details Log Incident details Prioritize and categorize Assign or escalate Investigate and Diagnose Locate Assignment Research Incident Identify cause/workaround Apply known resolution Resolve and Close Restore service Update documentation Customer validation Automatic Incident closure

Questions?

For More Information