Reference Field Auto-Complete Attributes

If you've ever used a reference field, you've probably seen that when you start typing, an auto-complete drop-down appears, to help you out. The info that appears in this auto-complete drop-down, is usually the display value for a given table (that is, the field which has the display property set to true). 

There are many cases where you may want more information than that. Maybe you've got many records with similar (or even identical) display values/names. Maybe you're referencing the user table, and want to make sure you don't select the wrong "John Smith". 

Read on to learn more! 

Read more

GlideRecord & GlideAjax: Client-Side Vs. Server-Side

It is easy to shoot yourself in the foot when it comes to performance, using client side scripts. For this reason, it is generally good practice to move any complex processing, large requests (more than a hundred or so records), and multi-level dot-walking to server-side scripts such as business rules which can present the data to the client. This can be done in a few ways, such as by using GlideAjax. It's also a good idea to utilize callback functions in almost every case where you're doing record lookups client-side. 

In this article, we'll go over some of the best ways to get the greatest client-side performance out of ServiceNow, by using good coding practices, callback functions, and GlideAjax to push some of the work off onto the server, rather than the client and prevent the client from having to wait around for the server to respond. 

Read more

Make Your Log Entries Easier to Find

Like most developers, I write a lot of code. 
Like all developers, sometimes my code doesn't work. 
When that happens (server-side), I rely on gs.log() to spit out some information to tell me when, where, and maybe even how the error happened. 

gs.log() is an extremely useful little function that is great for troubleshooting your code in dev, as well as catching unexpected behavior or circumstances in production. 
For example, you might have your code run inside a try { } block, but have the following catch() { } log the error message and accompanying run-time technical details using gs.log(). 
Or, you might write your code so that if a function receives some unexpected data, a log entry is created with the details, while the user is informed using gs.addErrorMessage(). 

The problem is that whenever I make one of these logs, I find myself sifting through tens, hundreds, or even thousands of other log entries to find just the one that my code triggered - and of those, just the one that was triggered by the most recent execution of my code. 
What's even worse, is if a user has to let me know about a bug or error they got, but they can only tell me that it happened "around Thursday". How am I supposed to find that log!? 

Join me after the jump, and not only will I teach you how to do it, but I'll give you a file you can deploy in your instance to enable this functionality within minutes! 

Read more