Posts Tagged ‘Incident management’
Posted by Mark Stanger in System Definition Monday, 19 April 2010 13:40 8 Comments
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:
- Easy to view and manage lookup table for common assignments
- Dynamic lookup/population of assignment values as you work on the Incident form
Posted by Mark Stanger in Scripting Thursday, 31 December 2009 17:06 4 Comments
O
ne common problem I encounter with Service-now deployments has to do with the sharing of a field between many tables extended off of the same parent table. Because the Task table and the Configuration Item table make heavy use of extended tables this is where I see the problem most often. What is the best way to make changes to a shared field for the table that I’m working on, but not impact other tables that may be using the same field?
Let’s say that I’m in the middle of a Change management deployment and I’m using the ‘Configuration item’ field on my Change form. At the same time, my company is trying to roll out Incident management so there’s also someone from another department trying to make configuration changes to the ‘Configuration item’ field on the Incident form. The Incident management process says that the Configuration item field is optional while Change management says that it should be mandatory. Incident management has a very complex reference qualifier for the field, but Change management doesn’t want a reference qualifier at all. Since there is only one dictionary entry for the Configuration item field, we can’t both have our way if we are making configuration changes on the dictionary entry. Below are a few of the common scenarios where you might see this problem and how you can make it work for all tables that access the shared field.
Posted by Mark Stanger in General knowledge, Scripting Thursday, 31 December 2009 08:26 No Comments
I
f you’re new to Service-now you’re probably realizing that there are a lot of cool things that you can do with the product. In most cases, the functionality you need is already set up and ready to go. Other things can be accomplished by installing a plugin that fits your particular need. In my experience, there are a few plugins that end up being used (or should be used) on almost every Service-now.com installation.
Recent Comments