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!
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.
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.
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.
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.
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.
H
ere’s a useful script I’ve used before to grab parameters from a URL in Service-now.com. Simply pass the name of the parameter into the function and it will return the corresponding parameter value.
So if you had a Service-now.com URL that looked like this…
https://demo.service-now.com/incident.do?sys_id=-1&sysparm_query=active=true&sys_myparm=abcde
You could get the value of the ‘sys_myparm’ URL parameter by calling the function below like this…
Here’s the ‘getParmVal’ function…
Home 
Integration tips and tools 
Twitter Feed snc tweets 
Downloads SNCGuru apps 
About/Contact 
About about SNCGuru 
Contact contact SNCGuru