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

Detect/Prevent Update Set Conflicts Before They Happen

Do you have multiple developers working in the same instance? If so, there's a good chance that on at least several occasions, one of them has "stolen" an update/record from another. I'll explain what I mean by way of an example:

  • Developer A is working on a project that involves changing a script include. 
  • Developer B, working in parallel on a separate task, also changes the script include.
  • The update sets are pushed. Depending on the order, at least one developer is likely to see results in production that they do not expect based on their development. 

So, how can we prevent these kinds of conflicts/confusion? 

What if we could alert a developer whenever they're viewing a record that is captured in another active update set, that does not belong to them--

Read More

Array.indexOf() not working in ServiceNow - Solution!

I'm baffled that this little issue has never cropped up for me until now, but I recently discovered a little annoyance in ServiceNow while iterating through an array. This issue had me going round in circles for hours, so hopefully by sharing my findings with our readers, I can spare some folks the frustration I felt.

First, I'll tell you a little story about how it happened to me, and then I'll tell you the explanation for this odd behavior.

Read More

Understanding Dynamic Filters & Checking a Record Against a Filter Using GlideFilter

I recently found myself in a situation where I had to check if a given record (the 'current' object in my case) matched a filter associated with another record (a client script, in my case). If you find yourself needing to do something similar, it might help you to know about an undocumented Glide API called "GlideFilter".

GlideFilter takes two arguments: 

  1. A glide record containing the record you'd like to check
  2. The query string (aka "encoded query") you'd like to check it against. 

The first argument may be self-explanatory - it's a GlideRecord object containing a single record.
The second argument, if you're not familiar with encoded queries, is a string of text that represents a query. If you've ever built a query in a condition builder, you've built an encoded query.

Read More