Whether you’re a new administrator or an experienced consultant, you need to know these things to become a master of the ServiceNow force.
Whether you’re a new administrator or an experienced consultant, you need to know these things to become a master of the ServiceNow force.
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.
I
‘ve been meaning to write about the different kinds of Glide popups available in Service-now for a while but haven’t really figured out a good way to show all of the different pieces that make them work. Instead of putting all of the information in one article I’ve decided to publish 2 or 3 different articles showing some of the different things I’ve done in the past. Look for more articles on Glide popup windows in the future. If you want to see all of the articles I’ve written about GlideDialogWindow and popups in Service-now just use the tags at the bottom of this article.
This article shows how you can pop open a list of records in Service-now using a couple of different methods. It also shows you how you could use a UI Macro icon to invoke either of these popup types.
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.
BSM
maps (Business Service Maps) are a central feature of Service-now.com that allow users to view a visual representation of the Service-now CMDB and the Business Services and CIs that those services are composed of. Service-now BSM maps also allow you to display additional information about (and take action on) the CIs represented in the map through the use of BSM Map Actions. I was recently working to create a BSM Map Action that I wanted to display for particular types of CIs and I couldn’t see how to set up a condition that would allow me to identify the type of CI.
What I learned is that each BSM Map has certain information available through URL parameters and through a ‘Data’ object about each node on the map. I just had to find the right piece of information! The solution was to use something like the following in my ‘Condition’ field on my BSM Map Action definition.
Service-now allows administrators a lot of flexibility in defining which elements appear on a particular form or list. The set of fields and related lists that appear are collectively defined as a View. One common configuration task is to somehow limit access to a particular view based on a user role or some information on the record being viewed. Instructions for working in some of these scenarios can be found here…
–View Rules
–Restricting Form Views by Role
Neither of these methods work if you need to change the view of a form from a client script or a UI action. In order to do that, you can call the ‘switchView’ function as follows…
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.
A while ago I wrote about some of the different ways to customize the autocomplete search behavior for a reference field. I saw a forum post the other day where the poster asked if it was possible to create aliases for records so that they could be searched on. For example, what if you had a CI called ‘ABC’ but everybody knew it by the name of ‘XYZ’? While support for this type of searching isn’t really built into Service-now, it is possible to add this kind of behavior to a reference field. If the CI just had a single alias, you could probably just customize the display value and do a ‘contains’ autocomplete search as described in the article previously. For this specific scenario I think that there might be a better way to accomplish the same thing.