ServiceNow Administration
Incident Overview
What Is an Incident vs. What Isn't an Incident?
Per ServiceNow, the goal of Incident Management is to restore normal service operation as quickly as possible, while minimizing impact to business operations and ensuring quality is maintained.
Before working on an Incident, do some initial investigation to see whether the Incident is truly something that is broken or if it is working as designed but doesn't meet the current needs of the person that created the Incident.
Incident Validation and Investigation
There are several ways to determine if an Incident is a true break / fix or should be an Enhancement.
- Check the component(s) tied to the functionality in question, per the INC.
- As you've identified those components, check the Versions Related List of those components (Business Rules, Script Include, Client Script, UI Action, ACL, etc.) and determine how or why it is configured the way it is. Use the Update Set naming convention to track the configuration back to an ENHC, STRY, INC, CHG, etc.,
- The Version of the configuration you are looking at in the instance is the Version indicated with State -> Current.
- If the versions contain no entries, this is likely an out of box component or configuration. If the version contains an entry with Source -> Default, this may have been a configuration that was done directly in the instance and not in an Update Set to be used for code promotion. This violates best practice.
- To determine who made the configuration change or if it is out of the box:
- Open the Version record by clicking on the Name in the Related List.
- Created by and Updated by, on the Update Version, only indicates who created the Version entry in the instance by promoting the configuration into the instance (via an imported XML or applied Update Set, etc.). This isn't necessarily the user that made the configuration changes.
- Check the XML Payload and look for the sys_created_by and sys_updated_by values. If these are configurations that were created by a user, sys_created_by should be an instance user name. If these are configurations that were updated by a user, sys_updated_by should be an instance user name. If these configurations were created by or updated by the system, sys_created_by and/or sys_updated_by will be a snc (ServiceNow) user name, system, admin or glide.maint.
- IF VERSIONS AREN'T A RELATED LIST ON A RECORD:
- Right click the record header -> Configure -> Related Lists
- Move Versions from the Available list collector to the Selected list collector and click Save.
- Open the ENHC, STRY, INC, CHG, etc., in the Update Set name. Determine if the functionality and how it is described as a problem in the Incident is contained anywhere in the Parent record (source of the way it is configured from the Update Set name, discussed above). If this Update Set was for an STRY, for example, read the STRY Description, Acceptance criteria and read the Activity feed for test results. Check any requirements documents attached to the STRY.
Incident vs. Request vs. Enhancement / Story
After investigating and determining if the platform is working as intended, a determination should be made on if this is a valid Incident. If this is not an Incident, Resolve the Incident with valid Closure Information and have the user submit a Request or work with the Product Specialists and user to get this turned into an Enhancement or Story.
If Request
Typically, a Request is a predefined good or service that is offered. If this is something that is frequently fulfilled in the same way, it is likely a Service Catalog Request or we should consider creating this frequently fulfilled item as a Service Catalog Request through the Agile Enhancement process (see If Enhancement / Story below).
If it is determined that an Incident should be a Request, the admin should provide a link to the Service Catalog Item in the Work Notes and via an email to the user that opened the Incident and set the Incident to a Resolved or Cancelled state.
If Enhancement / Story (Note that this is specific to our Agile 2.0 Environment)
A story is a brief statement of a product requirement or a business case. Typically, stories are expressed in plain language to help the reader understand what the software should accomplish. Product owners create stories. A scrum user then divides the stories into one or more scrum tasks. An enhancement is like a story but it typically involves a modification or customization to existing functionality to accomplish fulfilling a product requirement / business case.
If it is determined that an Incident should be an Enhancement or Story, the admin should work with a Product Specialist / Business Analyst (this type of role can vary by organization) by engaging them via an email and include the user that opened the Incident. Provide a link to the Incident and why it should be an Enhancement or Story. Set the Incident to a Resolved or Cancelled state. The Product Specialist / Business Analyst should be able to work with the user and create an Enhancement or Story and work with you, if necessary, where there are questions or gaps.
