Welcome to K23 - Las Vegas - IT Service Management Fundamentals.
If you are in the K23 ITSM Fundamentals class in room Cassanova 607, Please post any comments or questions here using the COMMENT button. Classroom staff will be monitoring this conversation during class on May 14-15, 2023 and will answer to the best of their ability. Also, feel free to refer back to this article post knowledge.
NOTE: This article will not be monitored post K23.
NowLearning.
This the official training web site for service now. You can get free trainings and extra knowledge
Hello! I'm Karen from San Antonio. I'm the manager of our service management team. We're so new to ServiceNow that we haven't purchased it, yet. I'm here to learn about the software and best practices for setting it up, preferably as close to out of the box as possible.
Hey team! Welcome to the ITSMF class at Knowledge, it's going to be a great, interactive couple of days. Take notes using your new Rocket book and remember, only use the pen that came with it so that you can erase and reuse it later. Raise your hand for any questions or post them here, we'll be monitoring and answering as we go. Let's get learning!
Absolutely an incident can lead to a change. Incidents (issues) are how we find something that needs to be changed! It needs to be recorded as a change so . . . if something else happens . . . you know what exactly happened and how to undo it. Hopefully you have multiple environments, and have tested prior to implementation so an UNDO is not required!
Hello! I'm Karen from San Antonio. I'm the manager of our service management team. We're so new to ServiceNow that we haven't purchased it, yet. I'm here to learn about the software and best practices for setting it up, preferably as close to out of the box as possible.
In the CMDB, is it better to list "owned by" as a person or a group name? If the person leaves, is it difficult to change the name if there are a large number of items owned by that person?
How do you provide visibility into the Affected CIs (resources and services)?
If multiple incidents are created, but the root-cause CI is not added properly to the INC, how do you present better detection of the root-cause CI at the INC level? As an example to this question, multiple SDA's get INC from multiple servers so an INC is opened on each server by each SDA, but the issue is related to the Router/Switch all of the servers are connected too. How do you see the CI above each of the servers reporting an issue as the potential root-cause through the INC?
Is there a potential to utilize Knowledge articles (more specifically KEDB articles) that drive workflows in other record types? Are there examples of OOB functionality that supports these types of workflows or will this require customization to support this type of workflow?
For instance, when I link a KEDB article to an INC as the article used to resolve the impact of an INC, this drives a workflow to automate resolution codes and notes, and relationships to an existing PRB or DEF?
Are there any best practices pertaining to creating Assignment Groups?
As a practical example, a Tier 2 Service Desk team is divided into sub-domains within the same Tier 2 Service Desk team; Physical Infrastructure and Virtual Infrastructure teams. Should each sub-domain have their own assignment group for routing INC records between groups or should this be managed through Categories?
Hey there! Related to incidents/problems and creating tickets from those records. Two questions:
1) Can you create multiple tickets, say a 3 changes, from one incident record?
and...
2) When you create another ticket type from an incident or other record, does it change the status of the ticket you created it from to closed in an out-of-box implementation?
Was thinking about the question on whether or not it's acceptable to delete incidents in the system. At the law firm I work at, we've had a few situations where either a help desk agent or a user includes sensitive information in a record (credentials, privileged client info, etc) and the office of the general counsel or infosec asks us to delete the record immediately.
Yes, an incident and/or problem can lead to a change. The user will categorize when the incident is raised. The user will not convert it to a change, IT will determine if the incident should be converted to a change or a problem
How do we enforce our customers to email our IT service desk for requests, and call for incidents? We have customers that directly call/email IT members because they don't want to wait. Some customers skip the service desk entirely and go to an analyst that has helped them previously. How can we break this habit? We want our customers to go at least through the service desk so that we could document what issues were dealt with and with whom.
@birkelbkIn the CMDB, is it better to list "owned by" as a person or a group name? If the person leaves, is it difficult to change the name if there are a large number of items owned by that person?
That owner is usually part of a group with certain roles. When an employee leaves, policies and workflow processes should be deployed remove access/ownership and replace ownership
Is there a way to send a real time system alert/notification to agents actively logged into a SN instace? For example, if a parent incident to help manage an outage, we could sent an alert to the Help Desk group instructing them to attach children incidents to parent for any new associated end-user calls.
The Status Bar at the top of Change and Problem is a very nice visual status... why not have that on the INC level as well? NEW -> In Progress -> On Hold -> Resolved -> Closed it can also be update if a promotion to MI has been approved, NEW -> In Progress -> On Hold ->Major Incident -> Resolved -> Closed
A Major Incident should never be put on-hold, so I wouldn't make that an option/level, IMHO, and not a practice we follow.
I would like to see a visual indication in the Incident list that an Incident has been proposed to Major Incident and another once it's been promoted to Major Incident. For sure the latter. Similar to the Red dot in front of 1-Critical incidents have something to quickly see and identify incidents that are at the Major Incident level.
Additionally, there needs to be a visual indicator/flag at the INC level (other than the Major Incident tab) to quickly let the Incident Manager know that INC is a MAJ INC. Just like the Red Major Incident Flag seen on the Workbench view.
Is there a potential to utilize Knowledge articles (more specifically KEDB articles) that drive workflows in other record types? Are there examples of OOB functionality that supports these types of workflows or will this require customization to support this type of workflow?
For instance, when I link a KEDB article to an INC as the article used to resolve the impact of an INC, this drives a workflow to automate resolution codes and notes, and relationships to an existing PRB or DEF?
KEDB will be associated if there is a relationship to the PRB. A DEF is related to Alige 2.0 to an associated STRY
Regarding the question about instance availability, you will have access to these only until the end of class today. Please remember, you can visit the ServiceNow Developer site and click "Request Instance" where you'll be provisioned your own instance that you could use to walk through the labs again if you'd like.
Are there any best practices pertaining to creating Assignment Groups?
As a practical example, a Tier 2 Service Desk team is divided into sub-domains within the same Tier 2 Service Desk team; Physical Infrastructure and Virtual Infrastructure teams. Should each sub-domain have their own assignment group for routing INC records between groups or should this be managed through Categories?
It's hard to provide a "best practice" around this use case....as you typically need to dig more into how the org wants or plans to operationalize things. In some cases, you might just use a single assignment group (and use 'skills' for routing).... but the requires a certain level of maturity....in that the company has skills defined and can tie skills to your users and issues.
In some cases it might make more sense to to use separate assignment groups... for example, say the organization uses on-call support schedules and based on how they operate for on-call support, it might make more sense to have separate assignment groups for that use case example.
So there isn't really depends the way with how you approach defining your support assignment groups and governance is key.
Was thinking about the question on whether or not it's acceptable to delete incidents in the system. At the law firm I work at, we've had a few situations where either a help desk agent or a user includes sensitive information in a record (credentials, privileged client info, etc) and the office of the general counsel or infosec asks us to delete the record immediately.
How do we enforce our customers to email our IT service desk for requests, and call for incidents? We have customers that directly call/email IT members because they don't want to wait. Some customers skip the service desk entirely and go to an analyst that has helped them previously. How can we break this habit? We want our customers to go at least through the service desk so that we could document what issues were dealt with and with whom.
Can you detail the relationship of PRB records interact with RCA's that need to follow through the defect lifecycle mgmt and Release Mgmt lifecycles?
Where release mgt and managing defects for the stories/epics is in a software development lifecycle - project based. The defects are dealt with, within the sprint cycle within a project. Once all the the defects are remediated for the release - after go-live in production instance and hypercare(still using defects with the stories, post-go live) is completed. Then the features of that release is now operational/BAU in production and no longer a project. If a PRB is created based on the implemented feature that is now in operation(no longer in hypercare) and a RCA has been done that requires a change, either a normal or emergency based on (impact x urgency = priority) business criticality.
To some level of frequency, we run into situations where there's an active INC - Outage on a CI that conflicts with a CHG that's coming up or that someone is wanting to start. Is there any current, or planned, mechanism to detect INC conflicts before moving from Scheduled to Implement to notify the implementor that there may be a potential INC opened that may impact the CHG activity?
I found the Major Incident Management training course.... all good here. Thank you.
INTERMEDIATE - 3 Hours
Major Incident Management Fundamentals
This course teaches users how to leverage ServiceNow Major Incident Management to increase employee productivity and minimize disruption to end users by ensuring business continuity with streamlined service restoration and communication activities.
Available As: ON-DEMAND COURSE
INTERMEDIATE - 2 Hours 48 Minutes
Major Incident Management Implementation
Learn how to configure the ServiceNow Major Incident Management application, including supporting integrations to collaboration tools.
