Working effectively with ServiceNow
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1
- Forks
- 9
- PR merge metrics
- No merged PRs in 30d
Description
General ServiceNow setup
Effective RITM and INC column setup
You can change the visible columns using the "Gear" icon at the top-left of the panel. Columns stay constant across filter favorites. I am not aware of a way to have column favorites to switch between.
RITM Columns
- Number: The RITM number like
RITM0123456. - Assigned to: which RC team member is responsible for this request.
- Updated (sort descending by clicking this column until a downward triangle appears): Date of most recent update.
- Updated by: Who most recently updated the RITM. Useful for finding tickets that need attention. Any ticket with a non-RC BlazerID here probably needs attention.
- Created: Date of creation.
- Requested for: Lets us know which tickets haven't had "Guest" updated to the actual person. Also, helps narrowing down tickets we are trying to find.
- Requester: Generally should be the same as "Requested for", but may differ if the ticket was created by one of the RC team for someone else. This is uncommon, but can help if we need to find out information from that RC team member.
- Tags: Allows us to quickly distinguish between ticket contents to assist with triage and finding specific tickets. Can be modified in the RITM table!
- Short Description: Same as tags but should not be modified.
- Closed: Date of closure
- Closed by: Who closed the ticket. Helpful for getting information on why a ticket was closed. This has yet to come up.
INC Columns
- Number: The INC number like
INC0123456. - Assigned to: which RC team member is responsible for this request.
- Updated (sort descending by clicking this column until a downward triangle appears): Date of most recent update.
- Updated by: Who most recently updated the RITM. Useful for finding tickets that need attention. Any ticket with a non-RC BlazerID here probably needs attention.
- Created: Date of creation.
- Customer: Lets us know which tickets haven't had "Guest" updated to the actual person. Also, helps narrowing down tickets we are trying to find.
- State: An important, high-level UAB IT metric is minimizing SLA (Service Level Agreement) Breaches. Incidents that are left open too long without attention are considered a breach. Breaches reflect negatively on RC and on UAB IT. Three email warnings are sent to all members of RC at 25%, 50% and 75% time elapsed before the breach occurs. To avoid a breach, the state must not be "Open" nor "Work in Progress". If a ticket is still being worked it should be either "Pending User Info" when we are waiting for a reply or "Pending Problem Management" when we are waiting on an internal step to complete.
- Tags: Allows us to quickly distinguish between ticket contents to assist with triage and finding specific tickets. Can be modified in the INC table!
- Short description: Same as tags but should not be modified.
Setting up RITM and INC filters for common tasks
Saving filters as favorites
INC processes
Incidents are used by Enterprise IT to track issues with mission critical systems. By process, all AskIT requests start their life as an incident, and get converted or dealt with as appropriate.
We prefer to deal with Request Item tickets rather than Incidents. We have a set of customized scripts that converts support@listserv.uab.edu emails into RITM, and allows our team and our researchers to interact with RITM via email. So ideally we want to convert all Incidents to Requests. Conversion does not copy any notes onto the Request, effectively losing the history of the Incident. So, if there is a history, we may not want to convert.
New Incidents
An Incident is "new" if it does not yet have a conversation in the "Notes" tab. We want to convert these Incidents to Requests.
- Ensure INC is in Research Computing scope and handle accordingly if not. See [out of scope] below.
- In the hamburger menu, click Convert Incident to Request and follow through on the dialogs.
- Follow the RITM intake process.
Existing Incidents
- Make sure that
support-watch@listserv.uab.eduis on the "Watch List". If not, [add it] and click "Save". - Make sure the requester's
@uabmc.eduemail address is on the "Watch List" if they sent their email from that address. If not, [add it] and click "Save". - Make sure the "Customer" field reflects the actual person who sent the request, if they are affiliated with UAB, i.e., the request came from
@uab.eduor@uabmc.edu. If the request came from another email, then leave it as "Guest".
Closing Incidents
RITM processes
- Make sure that
support-watch@listserv.uab.eduis on the "Watch List". If not, [add it] and click "Save". - Make sure the requester's
@uabmc.eduemail address is on the "Watch List" if they sent their email from that address. If not, [add it] and click "Save". - Make sure the "Requested for" field reflects the actual person who sent the email, if they are affiliated with UAB, i.e., the request came from
@uab.eduor@uabmc.edu. If the request came from another email, then leave it as "Guest".
Adding Tasks for Ops
Common processes
Identifying and handling out-of-scope tickets
- Every so often we get a ticket about servers or storage outside our scope, or questions intended for "Research Administration" (we are next to each other in the "Business service" list).
- Identifying these tickets takes some experience, so don't be afraid to ask in Slack if the ticket is in our scope or not, if you're unsure.
- If the INC is out of scope, change the "Business service" field to "AskIT" and click the "Save" button.
- Add a "Work note" under the "Notes" tab stating something like "This ticket is out of scope for INC because the server is not part of our platform."
How do I add people and email addresses to the "Watch List"?
How do I change the "Requested for" field?
Linking tickets in Slack
Triage
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the draft in issue #42; no repository files or tests are named. Clarify the intended documentation scope, then check the ServiceNow setup, RITM and INC processes, and common-process sections for completeness and consistency before considering the guide ready.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100