Month: February 2020

I come across plenty of interesting, blog-worthy bits and pieces while working my day job, but it wouldn’t be right to stop and write up a blog post on the company dime, so I tend to just jot down an (often cryptic) note when I come across something and then proceed on with whatever story or project brought the tidbit to my attention.

Then, when I have a bunch of items that need blogged about, I’ll take an hour or two after work or on a weekend, write up a bunch of blog posts, and then schedule them to go live at a rate of one per week.

That means that the stuff hitting my blog is unfortunately generally weeks or even months old, which is unfortunate because it’s not as representative of my current skill level, but that’s a trade-off I have to make in order to avoid missing large chunks of time where I’m supposed to be posting blog entries, but am tied up on some consulting project that is eating up all of my non-work time.

Currently I’m doing some consulting after hours which has meant blogging time has been non-existent for several months now, and some of my cryptic entries are even older and therefore more cryptic than normal.

One of my notes is something to the effect that when an outbound API call from ServiceNow fails, it will trigger a catch (from a try/catch), which means that you can log that it failed, but that whatever is failing is lower-level than the script calling the API, and that something doesn’t pass the normal error message, which means that it’s a lot harder to debug that particular issue than it otherwise would be.

I don’t remember the exact circumstance around this note though, so I haven’t done my normal testing before writing this blog post. All of which means that you’ll want to take this particular find with an extra grain or two of salt.

I very much understand the necessity of ACL’s in ServiceNow, but it’s taken a couple of different stories (we work using SCRUM at my day job) for some of the intricacies of ACL’s to sink in for me. A lot of the stuff that was tripping me up early on was very basic, but a couple of things that I’ve come across feel more like idiosyncrasies to ServiceNow that will cause me grief again at some point, so those are things that I need to document for future me’s benefit.

A case in point: it turns out that in order to create a new record in a table, you not only have to have the ‘create’ rights, you also have to have ‘read’ rights on the table. I would have expected that just having create rights would do the trick. It’s possible that I misunderstood what was going on though, so I’m documenting my experience here and then I’ll test that out the next time I have a story that involves adding new ACL’s into a ServiceNow instance.

Just a quick note–I’ve realized since my post a few weeks ago that JSUtil.logObject() will tell you that you’re dealing with an array if you pass it an array.

I had an interesting experience recently. I was working on an ACL, and my initial approach involved adding a script to the ACL. As I continued working on the story that required the ACL, I unchecked the ‘advanced’ checkbox on that ACL, and then tested the user’s access again.

Much to my surprise, I realized that the script was still running even though the ‘advanced’ checkbox was no longer checked.

As nearly as I can tell, the checkbox hides the script from the user, but it’s still running even though the script is hidden.

My expectation was that unchecking the box disabled (but didn’t delete) the script, but that appears to be wrong, so make sure if you want a script not to run that you clear out the editor rather than just unchecking the box.