Yea, we've unfortunately just had a tough time getting the data labels to present the percentage values we need. I'm hoping one day ServiceNow will develop more data label configurations but will definitely become more acquainted with targets and thresholds in the mean time and see if we can come up with a solution. Thank you for your responses!
I wanted to take a moment and thank you all for a jam packed two days here at K19 – I really enjoyed being your trainer.
Again, my apologies for any challenges my voice may have caused.
While I know your minds are probably swimming right now with all that we covered, the journey is just beginning. Over the next few days I predict you will suddenly have many more questions or realize there was something you really wanted to ask this week and did not. This is understandable – the platform can go pretty deep if you want it to and we’ve explored just a fraction of that iceberg (though if we’ve done our job well and adhered to Pareto’s Principal, that fraction of core information will get you pretty far), and I want to assure you that the answers you’re looking for will be there for when you need them.
Below you will find a collection of links to documentation, common practices and use cases, odds and ends I’ve personally found useful in my own ServiceNow experience, and a few links I’ve curated for this class based on general parameters. You’ll also find links to your local SNUGs (ServiceNow User Groups) and a few other useful community connections. Feel free to share with your customers, colleagues and more!!
I hope you’ll keep in touch and let me know where your transformation and learning will take you; perhaps I’ll see you next year at the 2020 Orlando Knowledge conference or have a chance to teach another class with you again in the future.
Sincerely,
Christian
P.S. Please don't forget to fill out the survey in the ServiceNow Events/Knowledge App.
Check out ServiceNow's Developer Portal– you can request a free personal developer instance that you can use as your playground to gain experience while your company works to implement the platform. There is also some training material on that site that you can looking at in addition to going back of the material we covered in this class and the labs we did. (One that I would highlight recommend you checking out is Technical Best Practice)
Look at ServiceNow's Community – that is our forum to ask and answer any question, followblogs, vlogs and podcasts of not only ServiceNow employees but from our user group. There are user and special interest groups you can join (I listed a couple below). As well as information regarding different events – everything from Webinars, on demand videos, NowForms (which are line one day user conferences) and our official annual User Conference Knowledge
Check out HI Service Portal. This is your central place to Find detailed information about managing your instance, requesting services finding solutions, and documentation. Visit the site for access to comprehensive product documentation and the latest release notes. And also to ask for future functionality.
Get involved with our ServiceNow User Groups or SNUGs – great place to meeting and network with other customers, consulters and administrators here are some links:
So here's a fun one that appears to be easy but I can't figure it out. I want to do a stacked column widget that shows the Top 20 Configuration Items selected in Incidents. We require a CI on all incidents, so I have the data I need, but can't tease it out. Do I use a breakdown source that is the incident table CI or do I use all CIs?
Since your business process data to analyze is Incidents, I would set up/use an Indicator Source/Indicator retrieving all Active/Open Incidents (both Source and Indicator already exist in the base configuration).
Because you want to segregate the data by CI, I would set up a Breakdown on the CI attribute. The Breakdown source should be the respective cmdb table and your Breakdown will maybe look for CIs of a certain type, or all CIs. Further, you will need a mapping to map the CI Sys Id to the CI reference field in the Incident table.
Now that you have the above, collect some historical data and make sure that your Breakdown correctly separates the Incident data by CI.
At this point your are ready to create a Widget. Since you need to display the Incidents by the CIs they reference, I would use a Breakdown Widget using the CI Breakdown. If there are too many CIs, you can use the built-in filters to display only the top CIs.
What is the best way to determine how many incidents a user has worked on but not necessarily resolved? I have a requirement to find out how many incidents a user has "touched" in a given month as well as average business duration an incident stays within their queue before either being resolved or reassigned.
I've tried using metrics, but I've found it's difficult to report on individual users because they come in as strings in the "Value" field. It's also challenging because when you report off the metrics table, you lose the ability to click in and view the individual incidents that were touched.
I have full access to Performance Analytics, is there a way to leverage this tool to accomplish this ask?
I would like to be able to find the average elapsed SLA time of all incidents in a given month. Manually calculating this would be (Total elapsed SLA time of all incidents / Number of incidents). The way ServiceNow calculates this is (Total elapsed SLA time of all incidents / Number of SLA stages of all incidents). Most incidents will have at least 2 stages: Response and Resolution. Suppose the total SLA time for an incident is 1 Hour, but the response is 1 minute and resolution is 59 minutes. ServiceNow reports (and performance analytics) will calculate the average SLA elapsed time as 30 minutes. This becomes even more pronounced if a ticket is placed in a “pending” state and reassigned multiple times (see attachment).
In this case the total elapsed time is divided by 8, making the average elapsed time around 3 hours. There are other time fields that do give a time closer to the total elapsed time, such as “Total Business Duration”, but these fields don’t take the pending state into account. The SLA elapsed time gives us the most accurate metric of how long it takes an incident to be resolved as far as the customer is concerned.
The assigned to metric (or assignment group) is a good way to capture duration of assignments. I would then create an indicator on top of it (like we did in class) and use a PA widget for reporting.
