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!
The first step in applying this customization is to create a priority lookup table that can store your priority matrix. The update set includes this table for you (which can be managed from the ‘System Policy -> Priority lookup’ module). Create, write, and delete ACLs are also included to restrict permissions to the ‘admin’ role by default.
—Table and field settings (along with necessary dictionary changes)—
Table: Priority Lookup
–Audit and ‘update_synch’ attributes included for ‘Priority Lookup’ table
Fields:
Impact – Choice field (Uses the Incident table and Impact field as choice table and field)
Urgency – Choice field (Uses the Incident table and Urgency field as choice table and field)
Priority – Choice field (Uses the Incident table and Priority field as choice table and field)
Once the ‘Priority lookup’ table is created and populated, you’ll need to modify the ‘calculatePriority’ business rule that is used to return the correct priority value to the incident record as its impact and urgency change. This business rule actually exists out-of-box, and you can find it by navigating to ‘System Definition – Business rules’ and searching for the ‘calculatePriority’ business rule on the ‘Global’ table. Once there, you’ll want to make sure the business rule is set up as follows…
Name: calculatePriority
Table: Global
Script:
var pVal = '4';
//Query the priority lookup table to find the priority based on impact and urgency
var rec = new GlideRecord('u_priority_lookup');
rec.addQuery('u_impact', impact);
rec.addQuery('u_urgency', urgency);
rec.query();
while(rec.next()){
pVal = rec.u_priority;
}
return pVal;
}
That’s it! Now you can modify the ACLs for that table if necessary so that a process owner has access and can modify the priority matrix without having to touch a single line of code. You can view the update set and installation instructions here…
Related Links:
- Download: Incident Priority Lookup
- Supporting Documentation: Installing an update set on your instance
wow. great! I then can enhacne the table to have priority matrixes per service and even for specific cis!!!
Improve performance of your instance and convert that Global Business Rule into an “On Demand” Script Include function instead. We were teaching folks at the Scripting in Service-now class that Global BR’s are BAD (per Tom Dilatush’s advice). As of Late Fall 2010 or Winter 2011, you can create Script Includes that are merely functions. The Script Include table is included in a more performance intelligent manner and only loads that code when necessary. Global BR’s just load all of them, all the time.
Completely agree. In this case, the system already has a couple of places tying into this global business rule so it’s the simplest way to make the modification without having to make too many other changes.
Mark
I like how the Priority Lookup works and the ease of changing the calculation. I have another question for the rest of the community to see.
We have a requirement in building incident to add a “Priority Override” checkbox that will allow a Service Desk agent to override a calculated priority. I’d like to leverage the Priority Lookup table to complete the calculation. For example, I may have an impact of Low, urgency of Low, and Priority Override is true which would equal a High priority incident. Which scripts would I have to modify in order to complete the calc?
Thanks for any help.
You would need to modify the ‘calculatePriority’ business rule to do the lookup including your new field. You would also need to modify the 2 priority calculation client scripts on the incident table that respond to changes of the impact and urgency fields to include your new field as well. Then you’ll need to create a new client script similar to the other 2 that will react to a change of your new field.