A
co-worker asked me for some help yesterday fulfilling an interesting requirement. He needed to set up a configuration item reference field or catalog variable that would display a calendar macro that, when clicked, would open a popup window containing a change calendar report for that configuration item. I figured this idea might be of use to others so I’m posting it here!
I
t should come as no surprise to you that, if used properly, your CMDB can be an extremely valuable input to your incident/problem/change processes. This is true not only of the actual CIs, but also the ‘Affected CI’ records that you create. ServiceNow gives you a couple of different places to track this information. The first is the ‘Configuration Item’ field available to all Task types in the system. You can add this field by personalizing the form for any task. The second is the ‘Affected CIs’ (task_ci) many-to-many table. This can be added to any task form in your system by personalizing the related lists for that form.
This setup allows you to track a primary CI or Business Service against a given task in the field on the form, and it also allows you to track multiple Affected CIs against a task if necessary in the related list. What I don’t like about this setup is that these are managed independently so there’s not a single place to see ALL of the Affected CIs in your environment. My solution to this problem has always been to centralize all of this information into the ‘Affected CIs’ related list by copying the ‘Configuration Item’ field value into it. This simple idea gives you a much better look into your Affected CIs for reporting, and allows for more proactive troubleshooting through CI Business Service Maps as an input into your task processes.
I
had a great time presenting on Advanced Incident Management last week at Knowledge11. During that session I demonstrated a lot of very useful functionality that I’ve used and created to improve the standard incident management setup for technicians working in ServiceNow. Since most of my presentation was a demo, I promised the attendees that I would post information about the solutions we talked about there. Read on if you want to see some great ideas to improve incident management in your organization!
One of the basic pieces of any ITIL-based incident management setup is a priority matrix. Impact and Urgency drive a Priority calculation that can then be used to prioritize work and drive SLAs (among other things). ServiceNow comes with these prioritization fields and also includes a default calculation for you. While this setup works fine, it’s not very user-friendly to configure. The priority matrix is completely code-based so admins are really the only ones who can modify it. You also have to know where that calculation takes place (the ‘calculatePriority’ business rule). It’s just not as simple as it should be.
Last week at Knowledge11, I presented at an incident management session. One of the things I talked about was how you can get yourself out of the code by using lookup tables. I’ve written before about Assignment Lookups and in this article I’ll show you how you can use a ‘Priority Lookup’ table to get away from writing and modifying your priority matrix in code and allow non-admin users to be able to manage this matrix for you. Special thanks to Ivan Martez and Martin Wood who came up with this idea!
H
ere’s a UI macro that I’ve used for a couple of clients that allows you to pop open an on-call rotation calendar for the group selected in any ‘Group’ reference field in the system. This will probably be most useful for the ‘Assignment group’ table that you use on the task table. As with any reference field UI macro, you can add the UI macro to your reference field by adding the ‘ref_contributions’ attribute to the dictionary entry of your reference field. So this macro would require the ‘ref_contributions=show_group_on_call_calendar’ attribute. Since it displays on-call information, it is also dependent on the ‘on_call rotation’ plugin being installed.
T
here are several ways to do time tracking in Service-now. One of the ways used frequently (especially in Incident Management) is the ‘Time Worked’ field. The Service-now wiki describes this functionality. I often see the requirement to have some control over the stop/start of this Time Worked field for customers using this functionality. This post describes the approaches I’ve used in the past to meet this need.
S
ervice-now provides the ability to automatically move incidents marked as ‘Resolved’ into a ‘Closed’ state after a certain number of days. In my experience I’ve found that this type of resolution/closure workflow is really the best way to configure your incident management setup because it allows end-users the ability to reopen incidents within a certain window (while they’re still marked as ‘Resolved’) but it also ensures that eventually all of the incident tickets move to a ‘Closed’ state where they won’t be reopened so that you can accurately calculate SLAs and reporting metrics.
The key piece to this auto close functionality is the ‘incident autoclose’ business rule on the ‘Incident’ table. It works in conjunction with the property shown here – that sets the number of days after which a resolved incident will be moved to a closed state. The ‘incident autoclose’ script works great but it is based off of a basic date calculation that doesn’t take into account any business hours or holidays. Shown below are some modified versions of the ‘incident autoclose’ script that take into account the default system calendar (in the case of calendar-based autoclose), or your choice of any system schedule set up in your system (in the case of schedule-based autoclose).
While most IT departments do their best to educate their end users and help them to solve their own problems as they come up, the need for users to contact the Service Desk is something that will always be there. Ideally, this contact takes place through a support tool like Service-now but chances are you’ve still got users who will contact the Service Desk directly by phone. As a result, Service Desk agents spend a lot of their time taking calls and logging tickets for those calls.
One of the challenges that I’ve seen a few times before with this type of arrangement is that people will call the Service Desk and start explaining who they are and what their problem is but the Service Desk agent doesn’t know if the end result of the conversation is going to be an Incident ticket or a Service Request. The way most of the forms in Service-now are set up requires you to make a determination about the type of ticket before you can start logging details about that ticket. As a general rule however, the Service Desk really needs to start recording the Caller information and the details of the call before they determine what type of ticket needs to be logged.
I worked with a co-worker of mine (Brad Hicks) to create the New Call application to help solve this problem. This custom application has been used by quite a few customers since as a standard Professional Services offering and has even made a couple of appearances at the Service-now ‘Knowledge’ conferences. I’ve been meaning to document the solution for a while and capture it in a redistributable update set. At long last, here it is!
Assignment rules allow you to specify conditions for which a particular assignment group and/or assigned to person should be assigned to work on a particular task. Assignment rules work fine, but as I’ve worked with clients I’ve come across some common scenarios that can’t be solved with the out-of-box setup. The primary issue with assignment rules is that they only run as a record is submitted and they only run if an assignment has not been made already to the ticket being saved. Along with this, most organizations I’ve worked with choose to make the ‘Assignment group’ field mandatory. Because of this, the person working the ticket always has to make some sort of assignment before saving the record (meaning that the assignment rules never get run). I learned how to work around this issue on one of my very first Service-now implementations and I almost always implement this solution as part of any Incident Management rollout. The out-of-box assignment rules are documented here. This article shows how you can apply the same customizations to your Service-now implementation that I use for my clients. This entire customization has also been packaged into an ‘Assignment Rule Lookup’ update set to save time in implementing.
This customization includes the following features:
Home 
Integration tips and tools 
Twitter Feed snc tweets 
Downloads SNCGuru apps 
About/Contact 
About about SNCGuru 
Contact contact SNCGuru