August 2019

ServiceNow Telephone Integration

I recently had the need to integrate a phone system with ServiceNow such that callers could input certain data (like an employee ID) while on the phone using an automated system, and then have the phone system hit a particular URL which allows the fulfiller answering the call to be taken right to a new incident with the caller’s information pre-populated.

If you ever need to tie your phone system to your ServiceNow instance, there is a good chance that you want this link:

The CTI Processing business rule specifically is where you likely need to go if you need to customize any of what the pre-built computer telephony integration functionality.

Built-in Translation Functionality For ServiceNow

I’ve written a bit about the translation project that I did for a client using the Google Translate API to dynamically translate incoming incident and request data.

I generally find that one of the more difficult part of most projects is figuring out what already built resources are out there that you can take advantage of.

That isn’t to say that the rest of the project is easy, necessarily, but for the most part, once I know what existing assets can be leveraged, creating the incremental improvements are usually pretty straightforward.

In the spirit of that, for anyone who might be coming at a translation-related project inside of ServiceNow, here are a couple of off the shelf translation assets that you may not know about already.

Firstly, the ability to create translations for existing field labels is a built in piece of functionality (I believe it only becomes available after you download one of the plugins for language translations (French, Spanish, etc.).

Once you’ve installed one of those plugins, you can add translations via the sys_translated table. It’s not dynamic (meaning that you have to put the values you want translated into the table before you need them, or write something of your own to dynamically populate that table), but it does create a much better experience for user who speak languages other than English.

The other bit of translation functionality that I leveraged in my project is the sys_ui_message table. Entries to this table are accessible using the built-in getMessage() function.

That allows you to put translations of common words or phrases into the table, and then pass the English value via your code and get back the translated value from the table.

I hope that one or both of those functions are helpful to one of my readers in the future!

Time Delay on Reverting and Reapplying

This is more of a fragment of a post than a legitimate post, but it still seem like something worth communicating. I’ll add additional information as my understanding solidifies.

I’ve been trying to track down a UI bug, and not having much success. Something is causing a comment to pop up on various UI Pages everywhere the UI Page incorporates a UI Macro.

I believe that the issue is stemming from reverting something to baseline as part of our next upgrade. Normally, I would expect that to be something that is quick and easy to isolate, but as nearly as I can tell, there is a delay between when a skipped upgrade is reverted back to baseline, and when it actually takes effect.

Part of that may have to do with a time delay in the reversions being pushed out to the various nodes that make up a given instance of ServiceNow, but there may also be more to it than that.

I reverted a script last week, and then went and checked the script subsequent to the reversion. It was showing as reverted on the upgrade history, but the actual script was still the changed version rather than the reverted version. I didn’t see the script actually revert until the next morning, which could mean that there is some kind of scheduled job that runs on a predetermined scheduled and the reversion didn’t take place until the scheduled job had run. It could alternately mean that there is a lag for some other reason and in that instance the reversion just took long enough that I didn’t see the change until the next morning.

I’ve also seen instances where the bug was occurring in spite of all of the reverted changes having been reapplied, and been ready to attribute the bug to something else entirely until it disappeared the next morning.

To summarize, I’m not sure if the UI bug I’m seeing relates to skipped upgrades being reverted or not, but I’m pretty positive at this point that reverted upgrades and changes being reapplied have a lag before they fully take effect.

Tracking a UI Macro Back To Where It Is Used

I’ve looked at a bunch of skipped upgrades at this point, but the group that has taken the most time has been the UI Macro skipped upgrades. Partly that is because there are so many of them, but it also has to do with the fact that I wasn’t quite sure how to track them back to the UI so that I could confirm whether or not there was something changing that I wasn’t anticipating from comparing the two different versions of the code.

After a good bit of effort around that, here is my process for tying things back to the UI.

1. Go into Studio and do a code search for the name of the UI Macro. UI Macros tend to be used either in other UI Macros, or in UI Pages.

2. If you have a UI Page pop up as using your UI Macro, then you can open that UI Page directly from inside of your code search. If you don’t have a UI Page pop up in the search results, pick one of the UI Macros that pop up, confirm that it’s really using your UI Macro, rather than something with a longer name that contains the name of your UI Macro, and then do a search on that UI Macro looking for a UI Page that contains it.

3. Once you have found a UI Page that contains your UI Macro, you can open up the definition–either from inside of studio, or by going to System UI > UI Pages. Towards the bottom of that page you’ll see a ‘Try It’ button that will allow you to open up the actual UI Page as seen by your users.

4. From there, you can compare a reverted version against your current, changed version, and testing out the functionality to make sure that you didn’t miss any breaking changes in your code review.

Version Tracking In ServiceNow

I’m currently reviewing a whole bunch of skipped upgrades at work, and had something that was perplexing me, so I thought that I’d share my findings with you.

I was seeing items that were coming up as being different from baseline, but when I looked at the version history on the item, it was showing one version from ~3 years ago that was the ‘current’ version of the script. There were also one or two versions with recent dates, but nothing before that current version.

All I could come up with was that no version history was being created until after a script was changed, and then once it was changed, only the modification was saved as a version in the history.

That accounted for the behavior I was seeing historically, but seemed like a sub-optimal way of doing things since it meant that you couldn’t easily compare your changed version to baseline–at least not before it popped up as part of a skipped change when upgrading from one version of ServiceNow to another.

I ended up submitting a ticket to HI Support asking for clarification on what I was seeing. It turns out that when you edit something, two versions are saved (the original and the modified version). That was what I’d been expecting to see, and honestly is something I should have tested before reaching out to HI Support, but that didn’t account for what I was actually seeing as I was looking at our skipped upgrades.

That, it turns out, is because ServiceNow had some problems with how they were doing version tracking ~3 years ago, so if you look at something that was first changed back in that time frame you don’t get the normal version tracking the way that it is done now.