In the Crossfuze Knowledge Turnkey, we’ve got a lot of great functionality. There are hundreds of updates that take the Knowledge Base to a whole new level. This includes full version tracking and the ability to revert to past versions for knowledge articles. When you’re looking at the various versions of a long article, however, it can be like trying to find a needle in a haystack to identify what’s actually changed between the versions.
After a bit of digging I was able to figure out how ServiceNow was doing those types of comparisons for update sets and versions of Business Rules, UI Pages, etc.
Some time ago we showed you how to refresh the left navigation pane via a script. The server-side solution in that article utilizes ServiceNow’s UINotification object/class. On versions prior to Calgary, this is the Java class Packages.com.glide.ui.UINotification.
There’s another use for UI notifications. In addition to refreshing the left navigator, the object can also be used to display informational messages. You’ve probably already seen these in your own instance. When you change update sets, the system reminds you by using a UI Notification similar to the one shown below:
f you’re like many of the customers I’ve worked with, you may have dealt with the frustration of having excess or redundant approval requests come to you from ServiceNow. This happens very often simply because the same user may be responsible for various different tasks in the system. For example, on a change request, I may be asked to approve as the ‘Requested by’ person’s manager, then again because I own one of the affected CIs, and then again because I’m a member of the Change Advisory Board! While this behavior may be desirable in certain situations, most of the time it’s completely redundant and annoying to end users. If I’ve already indicated my approval on a change as a manager, why should I be asked to approve again later? I’ve come up with what I think is a pretty effective solution to this problem that I’ll share here in this article.
A few weeks ago I came across an issue involving a Workflow Join Activity and some confusion around what it does and how it works. There is a little bit of documentation on the wiki but it still left some questions unanswered.
The purpose of the Join Activity is to combine two or more paths of execution after they have branched out. This serves the purpose of ensuring that subsequent activities will not get run multiple times with unexpected results.