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.
M
andatory fields are usually pretty simple to work with. Service-now provides simple UI policy and client script methods to make fields and variables mandatory. You may have noticed as you have worked with checkbox variables in the service catalog that these methods don’t apply. The reason for this makes perfect sense if you think about it. A checkbox has only two possible values…true or false. When the checkbox variable loads it is already set with a value of false (unchecked). Because of this, there’s never a situation where a checkbox variable wouldn’t satisfy a mandatory check. It will ALWAYS have a value!
What people usually want in these scenarios is to require a user to select a minimum number of options from a certain group of checkbox variables. In these scenarios, this minimum number of items checked really represents the standard for a mandatory check for that group of checkboxes. There’s not a simple way to handle these situations, but I’ve set up some client script solutions that allow you to perform this type of validation if it is needed.
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).
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.
H
ere’s a cool tip that I’ve actually wanted to know how to do for a long time. I can’t take credit for it though. I got the idea from a post of a Service-now customer admin, Garrett Griffin. So, thanks to Garrett for the inspiration. I think this is worth sharing with a larger group of users.
I’ve had several questions (one a day or so ago) about how you can return a distinct list of attributes from items in a table in Service-now. This is very simple to do in SQL, but there’s no direct approach to doing this from the Service-now UI. In this post I’ll show you how you can get this type of information both visually, and via script in your Service-now environment.
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.
I
‘ve seen a lot of requests on the forums asking how you can identify the button that got clicked form an onSubmit client script or a business rule. Usually the aim behind these questions is to make some field display or be mandatory based on a button click. While you can use client scripts and UI policy to do these things, there’s no built-in way to identify if a submit came from a particular UI Action. There is a way that’s been floating around for a while that you can do this and while it works, it’s not really the best way.
This post shows how to identify the UI Action that got clicked in an onSubmit script or business rule…the right way. In a single line of code you can return the Action name of the UI action and act on it accordingly.
Scheduled jobs are an extremely useful way to automate processes in Service-now.com and lift some of the administrative burden of the tool off of the shoulders of your Service-now administrators. It’s very easy to create a scheduled job or a scheduled import. Typically there’s no scripting or advanced configuration involved at all. Just set it up with a schedule and let it run! There are some situations where you might need to execute a scheduled job outside of its normal schedule. You can always open up the scheduled job entry and click the ‘Execute Now’ button, but there are also probably times where you’d really like to automate the process based on some trigger in a workflow or state change in some ticket or CI.
This article shows you how you can use script to execute an already-scheduled job on-demand. To do this, you simply mimic the behavior of the ‘Execute Now’ button by querying for the scheduled job you want to execute and firing off the job. Here’s the script…
List collector variables are a great way to collect multiple pieces of information about referenced records in a single variable in the Service Catalog. One complaint I get about these variables is that they take up a lot of space on the screen. While there’s not a lot you can do with regular slushbuckets in the system, List Collector variables have a little bit more flexibility because they can be manipulated with client scripts. Check out the SNCGuru List Collector archives for more examples of cool List Collector modifications you can use.
In this article I’ll show you how you can reclaim some of that Service Catalog screen real estate by modifying the size of a list collector variable using a catalog client script.
If you didn’t pay close attention to the recent Fall 2010 Stable 1 Service-now.com release you probably missed a really cool new piece of functionality. I just used it for the first time today and I really feel like it’s something that everybody needs to have in their Service-now Client Scripting tool belt. The functionality I’m talking about is the g_form getReference callback API.
The getReference() method is something that’s been part of g_form for a long time and is something that most Service-now administrators and consultants are familiar with. It’s extremely useful, but can also be a huge performance killer if not used correctly. The Fall 2010 Stable 1 release makes a slight tweak to the way you can use getReference() that can really improve the end user experience from a performance perspective.
Consulting Services CrossFuze Solutions 
Integration tips and tools 
Twitter Feed snc tweets 
Downloads SNCGuru apps 
About Contact Us! 
About about SNCGuru 
Contact contact SNCGuru