R
eference qualifiers are a powerful tool that every ServiceNow administrator and consultant should have in their tool belt. They allow you to dynamically filter the available options from a reference field. The ServiceNow wiki has some good documentation on this topic so I won’t re-hash that here. What I do want to address is the topic of Advanced Reference Qualifiers…specifically how to leverage a Script Include instead of a global Business Rule to run your qualifier script.
S
ervice catalog variables can be a challenge to deal with on standard forms when they are displayed in a variable editor. I’ve written before about different ways that you can solve one of these challenges…making the variables read only, so that they can’t be modified after the initial submission through the service catalog interface. Another common problem I’ve seen is that you can end up with a lot of variables that end up empty in the variable editor on your request item or task because they were optional or hidden on the front-end catalog form. If the variables are empty and you aren’t going to have users interact with them on the standard forms then there isn’t much use in having these variables show up at all in the variable editor.
Until now there really hasn’t been a good way to deal with this issue because of the challenges of dealing with so many different variable types in client-side JavaScript. A couple of days ago one of my colleagues, Jacob Kimball, suggested to me that we might be able to overcome this issue by using a ‘display’ business rule to collect the blank variable information at the server and then pass those variable names to the client. So, you can thank Jacob Kimball for the brilliance of this solution. I’m just spreading the love. 
E
very now and then I come across a question dealing with the order of execution for client-side code (Client Scripts and UI Policies). In my experience, the need to order client-side code is pretty rare and really only applies in a few ‘onLoad’ scenarios and even fewer ‘onChange’ scenarios. Usually, the way that a browser parses and executes client-side code means that the ordering is pretty unpredictable. It’s worth mentioning that this issue doesn’t exist with server-side code precisely because the browser isn’t involved (which is why you can neatly order all of your business rules without issue).
In this post I’ll show you some of the techniques I’ve used in the past to provide some control over the order of execution of client-side code. I’ll also show you a pretty cool trick that you can use to ensure that a piece of client-side code runs before any other client script or UI policy…or after ALL of those scripts finish running.
H
ave you ever wondered how Service-now does the collapse and expand animations in the application sidebar? This same animation effect is also used when collapsing form sections or displaying service catalog variable hints. I discovered last night how this is done and you can do it to with a simple script!
A
lmost any database will have situations where a record in a table can relate back to other records in that same table. This happens in Service-now in several places and it’s common enough that you may find yourself building additional functionality that works this way. 
The classic case is the ‘Parent’ field. A good example is the ‘Parent’ field on the ‘Location (cmn_location)’ table. Each location record in Service-now can be related to a ‘Parent’ location. This allows you to build a nice hierarchy of locations within your Service-now instance. Unless you work in one of those very rare places that implements a completely flat location structure, this parent-child relationship is critical for representing locations in your system.
This same type of setup is used in other places (such as task tables) where a given record can result in the generation of another record of the same type. You may have scenarios where a change request can be the parent of other change request or where a major incident becomes the parent of other child incidents. In this post, I’ll address the problem of circular relationships that can exist when you’re working with parent-child relationships in Service-now.
F
orm sections are a great way to segment information on a form into pieces that make sense to be grouped together. The most common example of the use of form sections is the ‘Comprehensive Change’ form. If you want to learn more about how forms, form sections, and views work I HIGHLY recommend a post I wrote a while ago on the topic. When customers use form sections, the need often arises to be able to show and hide that form section with a client script onLoad or on some changed field trigger.
People have known how to hide these form sections based on an ID number (which corresponded to the order of the form sections on the form). This method works fine, but it fails as soon as you add a new form section or change the ordering of your form sections in some way. Because of this, there has long been a need to hide form sections based on the section name or caption. Nobody has been able to figure out a way to do this…until now. Read on for the details…
I
‘ve answered several questions in the past about the functionality of lock icons in Service-now. Lock icons appear on glide_list and URL fields. The most-common example is the ‘Watch list’ field on the task table. Service-now provides some system properties to manage the default lock appearance of these field types. There are times when a global system property doesn’t really meet the need you have however, and you need to lock or unlock these fields automatically using script. In this article I’ll explain how I’ve done these types of things before.
A
s a Service-now administrator or consultant, you may run into situations where it is necessary to identify the IP address of a user session before performing some action. These situations are almost always security-related. For example, you may want to restrict the ‘Delete’ operation for Change request tickets to users at a specific location, or you may want to show a particular UI action button to users whose sessions originate from a particular IP address.
I haven’t seen this type of request very often, but it is pretty simple to get this type of information in Service-now. This post shows you how.
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.
Home 
Integration tips and tools 
Twitter Feed snc tweets 
Downloads SNCGuru apps 
About/Contact 
About about SNCGuru 
Contact contact SNCGuru