TUESDAY, FEBRUARY 07, 2012

Posts Tagged ‘Business rules’

Schedule-based Date/Time Addition

Wednesday, 26 October, 2011 09:53 Written by Mark Stanger
9 Comments

I

was recently asked to help a colleague figure out some date calculations based on a schedule. The requirement was to calculate a future date based on the existing value of a date/time field. I decided to document this solution (and come up with a solution for a similar problem…date addition from the current date/time based on a schedule). Working with dates and schedules can really be a pain if you don’t have good examples to work from so hopefully these help somebody at some point. Read on for the full scripts.

Learn more ...

What Everybody Should Know About ServiceNow Security

Thursday, 30 June, 2011 10:56 Written by Mark Stanger
5 Comments

Follow these guidelines to make sure you’re using the right security technique for every situation!

Learn more ...

Track Affected CIs in One Place

Friday, 27 May, 2011 06:47 Written by Mark Stanger
5 Comments

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.

Learn more ...

Incident Priority Lookup

Monday, 23 May, 2011 08:21 Written by Mark Stanger
5 Comments

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!

Incident Priority Lookup

Learn more ...

Checking for Modified or Changed Fields in Script

Thursday, 20 January, 2011 06:35 Written by Mark Stanger
6 Comments

W

orking in Service-now, you’ll find that a lot of scripting tasks come down to identifying which fields changed on a form (client-side) or record (server-side). In this post, I’ll show you some different techniques to identify changed fields in both client-side, and server-side scripts. I’ll also show you a way that you can capture changed fields and values and print them in an email notification…without having to check every potential field in a record.
ServiceNow - Changed Fields

Learn more ...

Fixing the Fatal Flaw of Before Query Business Rules

Wednesday, 05 January, 2011 09:30 Written by Mark Stanger
13 Comments

I

‘ve written before on SNCGuru about how ‘before query’ business rules can (and should) be used to secure row-level read access to records in Service-now. While this usually works perfectly, there is one issue that I’ve seen come up continually that there hasn’t been a good fix for. Over the past few weeks, I’ve seen several incidents and questions about inactive users disappearing from reference fields in Service-now systems. You may have noticed this yourself when you’ve de-activated users or groups in your system. The culprit in these cases is the ‘user query’ or ‘group query’ business rule.

The recommended (but really not great) solution up until this point is to turn the business rule off and use a reference qualifier on the reference field that you need to see the user in. The reason this solution is a bad one is that there are over 300 user reference and list fields in your system! Not only is that a big pain (and a bad idea) to add that reference qualifier to all of those places, but it also does nothing for the countless places (modules, filters, reports, etc.) that have UI elements that work like reference fields but cannot be filtered with a reference qualifier! This isn’t a new problem, but I’ve come up with a new (and extremely simple) solution.

Learn more ...

Are YOU a ServiceNow Jedi?

Saturday, 27 November, 2010 12:30 Written by Mark Stanger
4 Comments

Whether you’re a new administrator or an experienced consultant, you need to know these things to become a master of the ServiceNow force.

Learn more ...

Client & Server Code in One UI Action

Tuesday, 31 August, 2010 05:45 Written by Mark Stanger
19 Comments

M

ost Service-now administrators and consultants know how to configure and use UI Actions. UI Actions are UI elements that can show up on a form or a list as a button, link, or context menu. When these UI elements are clicked they execute some JavaScript. Most of the time UI Actions are used to perform some server-side update to a record or records. In other cases, you can use the ‘Client’ checkbox on the UI Action record to execute some client-side JavaScript (including checking for mandatory fields).
But what if you need to do both? The classic case is when you want to click a button to make an update to a record, but only if the user has provided the correct input first. An example would be a ‘Reopen Incident’ button that changes the state on an incident record from ‘Resolved’ to ‘Active’. Usually you want to require the user to provide some sort of comment or additional information explaining why they are reopening the ticket. The problem is that you don’t always want the ‘Comments’ field to be mandatory so the validation needs to happen at the time the ‘Reopen Incident’ button gets clicked. Validation of mandatory fields needs to happen client-side but the update to your record needs to happen server-side. How can you accomplish both of these things with a single UI Action? This article shows you how.

Learn more ...

Testing for a Valid Record

Thursday, 17 June, 2010 13:38 Written by Mark Stanger
0 Comments

T

oday I came across a scripting issue that I actually see quite often. I can’t ever remember it when I need it so I’m going to document it here. The issue is this: when working in a client script or business rule, I need to only have the script run if the record is a valid record. For me, this issue really only comes into play when working with client scripting or UI policies. For example, I only want a script to run if the record hasn’t been submitted yet. The following scripts show how you can test if a record is a new record or not in your scripts.

Learn more ...

Identifying the sys_id Value of a Record

Wednesday, 03 March, 2010 06:26 Written by Mark Stanger
0 Comments

S

ys_id values uniquely identify each record in your Service-now instance database. While you should never try to modify these values, it is sometimes useful to know what the sys_id value is for a particular record. This article describes the different ways of identifying the sys_id value for a particular record.

Learn more ...

« Older Entries

Latest Comments

  • Mark Stanger: This functionality doesn’t connect to an FTP server. See this line in the post above…...
  • Mark Stanger: The report page is back-end XML so there’s no way to directly manipulate the behavior of that...
  • Mark Stanger: Due to some ServiceNow limitations, the localhost MID server option had to be removed.
  • Matt Haak: Is it possible to use this with the local Mid Server (mid.server.localhost) It appears from this community...