ITSM Q&A from the GOING LIVE Webinar for Kingston Release

[Lisa Latour]

Below is the ITSM Q&A from the Live Broadcast Webinar for the Kingston Release, Unveiling the Latest Innovations from ServiceNow

Register to Watch the webinar on demand.

---

Q: Regarding the exception for Benchmarks, I saw these exceptions on the documentation.
All ServiceNow customers are allowed to participate in the Benchmarks program by opting in from their ServiceNow production instance, except:
• Express customers
• Federal customers
• Customers with on-premise instances
• Managed Service Providers (MSPs) and MSP-managed instances
CDM Smith does have the Federal Government as a client or customer but I don't believe that this designates us as a Federal customer. Is this correct?

A: Yes, you can leverage Benchmarks in your environment. The government callout was specific to Government orgs and not those with government customers.

Q: How do these compare to each other or differentiate each other?

A: Major Incident (the Incident record) is where you can manage all incident-related information, e.g., impacted services, child incidents, affected locations, etc. for diagnosis and resolution process.
Incident alert management should be solely used for Incident response process including communication and collaboration. So, if you have pre-defined incident response/communication plan, it can be defined using Incident Alert and Incident Alert Tasks.

Q: Is there, or will there be, a conversion tool to go from CMS to Service Portal? Is the New Hire catalog item available as OOB with Kingston's Service Portal?

A: There is no conversion tool to go from CMS to Service Portal. Please refer to CMS to Service Portal transition documentation on our site.

Yes, the New Hire order guide is still available.

Q: How do I get to the workbench. when searching for workbench in the filter navigator I do not see this. My dev instance was upgraded to Kingston a few weeks ago will I need to upgrade again?

A: View Workbench UI action is available on the Incident form header when an incident is promoted to a Major Incident (Major Incident state = Accepted).
https://docs.servicenow.com/bundle/kingston-it-service-management/page/product/incident-management/c...

Q: Hi, our users, including IT users, don't have clear understanding of a difference between a Service Request and an Incident. We provided some level of training, but the challenge is still there. I was wondering if any improvements were done in Kingston to address this issue, especially with the introduction of AI. For example, can a user submit a form from the portal and the system will generate either an incident or a service request?

A: AI does not help here in Kingston. The simple definition is the traditional one “Something Broken” vs “Need Something”. For the end users, the portal experience should be seamless, meaning they don’t need to know. For your IT users, they work off a queue where a task (Incident or Request) falls into their queue. The onus would now shift to the process owners who should define this experience and ensure the right items are exposed in the catalog ensuring that depending on what action the user takes, the right incident or request is created and directed to the right group or person. I hope that answers your question.

Q: Is this applicable to Service Now Express?

A: The short answer is yes. However, you will need to be on the full ITSM solution, which all Express customers will be upgraded to by the end of 2018. I’m not sure where you fall in the upgrade schedule. Check with your ServiceNow Rep to look up your upgrade timing to the full ITSM product.

Q: How will a Jakarta version of Service portal be affected in Kingston release?

A: A very broad question, so not sure what level of detail you are looking at, but here a few links from our docs site pointing to the release notes for Service Portal and Service Catalog. I am also including specific documentation for Service Catalog in Service Portal.

Service Portal Release Notes
Service Catalog Release Notes
Service Catalog in Service Portal

Q: The example being used is only displaying a single quantity of each item. If you want to have multiple qtys. within one order can you do that? If you can, is it possible for each line item to be assigned to a different support group or be sent to a 3rd party vendor?

A: If you are specifically referring to the portal demos on the service catalog enhancements, then yes, quantity can be changed, it is a dropdown. The only time you cannot change quantity in the cart is when the item is part of an Order Guide and has been added to the Cart. For each line item within the cart, they do go to different groups depending on the workflow associated with the catalog item. However, if you are looking to do the same for quantity updates, then the product does not do that. You could get the logic in your workflow to do that for you and handle the same as part of catalog tasks. I hope that answers your question.

Q: Isn't a major incident the same as a problem?

A: A Major Incident is defined as an incident that results in significant disruption to the business and demands a response beyond the routine incident management process whereas the problem is a cause of one or more incidents.
Problem Management seeks to remove the causes of incidents permanently from the IT infrastructure. Major incident management provides a process flow for handling high-impact incidents.
There is a sense of urgency attached to the Major incidents, and the goal is to resolve the incident as soon as possible. A problem record should be created to identify the root cause."

Q: Isn't the whole use of Problem tickets, with the ability to relate multiple incidents together under one problem ticket the best way to do this? We currently have a problem management practice in place. How does this enhancement in Kingston work with this?

A: A Major Incident is defined as an incident that results in significant disruption to the business and demands a response beyond the routine incident management process whereas the problem is a cause of one or more incidents.
Problem Management seeks to remove the causes of incidents permanently from the IT infrastructure. Major incident management provides a process flow for handling high-impact incidents.

There is a sense of urgency attached to the Major incidents, and the goal is to resolve the incident as soon as possible. A problem record should be created to identify the root cause.

Q: Hi, our users, including IT users, don't have clear understanding of a difference between a Service Request and an Incident. We provided some level of training, but the challenge is still there. I was wondering if any improvements were done in Kingston to address this issue, especially with the introduction of AI. For example, can a user submit a form from the portal and the system will generate either an incident or a service request?

A: AI does not help here in Kingston. The simple definition is the traditional one “Something Broken” vs “Need Something”. For the end users, the portal experience should be seamless, meaning they don’t need to know. For your IT users, they work off a queue where a task (Incident or Request) falls into their queue. The onus would now shift to the process owners who should define this experience and ensure the right items are exposed in the catalog ensuring that depending on what action the user takes, the right incident or request is created and directed to the right group or person.

Q: So we have an incident form and variety of request forms. How can we ensure that a user selects an incident when something is broken and a request when he/she needs something. Can we have one form and based on the selection in the form either incident or a request would be created?

A: My recommendation here would be not to make your end user select, it would only confuse them further. Naming your categories and catalog items or record producers (along with the description within each) should be done keeping in mind end user experience. This goes a long way in making the end user experience delightful. More often than not, we end up using technical terminology or what we know and rarely think about how end users look at these same things. It takes effort to ensure you get it right, and you probably won’t on the first go, but if done right, makes it easier for both end users and fulfillers. We did a webinar on the Community which might help you – Click Here.

Q: Is the Major Incident Management capability domain aware (i.e. domain separated)?

A: Major Incidents capability is partially domain separated as the process spans across multiple table e.g. Incident, Incident Alert, Incident Alert tasks and Task outage.
From an Incident standpoint – It is domain separated. We have introduced Major Incident Workbench which can be only be accessed from the incident record.
Currently Incident Alert and Task outage is not domain separated. In future releases, domain separation will be fully supported for Major Incident Management.

Q: We operate with multi-tier resolvers. It seems like the Incident assignment is based on impact, urgency, priority and a short description. Wouldn't all of this need to be created in a Customer CMDB in order for AI to work?

A: I’m not sure about the multi-tier resolvers but as for Incident assignment to work in Agent Intelligence, the prerequisite is to train our ML model using your past incident data which has the assignment groups filled in.  Once the model is trained, all the admin needs to do is use the solution in the business rule that is provided to predicted Assignment groups. As for Customer CMDB, if there is a dependency I would code it in the business rule itself.

Q: Say John is an approved password change requester and he submits ""change Sam.Feed password to 'c4D3light' will this new AI do this without any human error checking? Like before the above is performed the server emails a tech, Fred, and Fred can read the request and the proposed answer to confirm before it is done or will this go on with no human input?

A: Agent Intelligence (AI) for ITSM that is released in Kingston is enabled to Auto categorize and Auto assignment group based on your past incident data (which you specify while training the model). We don’t have password reset addressed through this offering.

If you’d like to explore “automated password reset feature” we have a solution (through orchestration) and can get more details contacting your account rep."

Q: Are we eligible for upgrade if we have Jakarta express release?

A: Yes, you will ultimately be upgraded to the Kingston release of ITSM. It will happen after or as part of your upgrade to the full ITSM solution depending on the ITSM upgrade group you are part of. Reach out to your ServiceNow account rep to identify the timeframe for your upgrade.