Communicating Changes to Your Users (& Setting Default User Preferences in ServiceNow)

I was sending dank memes in the ServiceNow developer community Discord server this morning instead of being at all productive in any way whatsoever - as we do be doin' over there - when someone went and ruined it by asking an intelligent question.
Unfortunately, I found this question really interesting and was thus compelled to write this article about the ideas that flowed from that conversation.
And now you have to read it.
I'm sorry, everyone.

Background Info

The specific question doesn't matter for the point that this article is trying to make (which is about how to communicate changes to your ServiceNow environment), but it helps me illustrate the point of this article (which does, I assure you, have a point).
The question was about how to modify which fields are visible in the ServiceNow Incident activity history formatter thingy - for everyone in the instance.

An individual user can modify which fields' updates they see in the activity history of a ticket by clicking the filter icon at the top-right of the activity formatter, and then selecting from a list of audited fields. Only fields which are audited on the table in question can be selected, but as long as a field is audited (and you have permissions to see that field's value), you can select it from this list and see changes to this field in the ticket's activity history.

But this question was not about how an individual user can change which fields' activity they see; it was about how to change which fields show up in the activity history by default, for everyone.
"By default" tells me that the fields should still be audited, and should still be available for a user to select, but should be de-selected from the activity history formatter's filter (in the screenshot above) by default.

I happen to have looked into how the activity formatter works, so I know that its behavior is controlled by user preference records (in the sys_user_preference table). Specifically, this behavior is controlled by the "incident.activity.filter" user preference, the value of which consists of a semicolon-delimited list of audited field names followed by a comma and then true or false indicating whether the indicated user has chosen for them to show in their activity feed on that table (i.e. “assigned_to,true;cmdb_ci,true;incident_state,true;…” etc.

If you don’t know, this problem is an easy one to solve; you just create a default user preference record, like so:

  1. Navigate to the sys_user_preference table by typing sys_user_preference.list into your application navigator filter bar and pressing Enter.

  2. Check if you already have a default for this user preference by filtering for records where Name is {table_name}.activity.filter (i.e. incident.activity.filter), System is set to true, and User is empty as in this this encoded query:
    name=incident.activity.filter^system=true^userISEMPTY

  3. If so, you’ll want to modify the existing one. If not, create a new one.

  4. Set the Name field to incident.activity.filter, the Type field to String, the System field to true, leave the User field blank, and set the value to whatever you’d like the default value for this user preference record to be.

An easy way to determine what the value should be, is to set your own preference record to whatever you want the default selection to be, then just copy your own account’s user preference record value into your default one.

Okay, sure, but what about users who have already customized their own activity filter?

Those users will not be impacted by this change. Default user preferences only apply to users who do not have user-specific preference records.

What if I want these new defaults to apply to everyone, overriding any user-specific customizations they may have had?

Rude; but sure, you can do that. Just delete all of their user preference records. You’ll have to do this separately and manually (or semi-manually, with a script) in each instance of course; but it can be done.

Pro-tip: User preferences are not typically captured in Update Sets. However, if the System field is set to true, then they will be captured in your Update Set! This means you don’t need to push the “default” user preference record into your Update Set using something like my “Include in Update Set” tool (though you totally should have it in your environment because it’s awesome).

Communicating Your Changes

You’ve communicated with your stakeholders. You’ve decided whether to delete any user-customized preferences for this user preference. What’s next? Test and deploy?
Let’s imagine what would happen if we pushed a change like this to production without properly and adequately communicating it to our users.
We’d start getting calls right away. “It used to be like this, and now it’s like that! I don’t like it when things change!” - “I can’t see the date when the ticket was created in the activity history anymore! I need to be able to keep track of that! What if it changes!? Am I just supposed to ignore the possibility of time-travel!? Change it back!”

How do we avoid the abject rage of these bescorned users?

Well, that’s one option…

No, not like that! We do it with ✨communication✨!

But, how do we communicate this information?
We could set up a newsletter… but literally nobody would read it. Especially if it went out to everyone, instead of being targeted at the people to whom each change was relevant.
How can we make sure to communicate the changes we made only to those users to whom the changes are relevant, while making sure that all of those users understand how the changes relate to them?

Guided Tours, baby!

Sorry for calling you ‘baby’.

Okay, I know, Guided Tours in ServiceNow kinda suck. They’re incredibly fragile, they don’t work in a lot of situations, they were straight-up just broken in the Vancouver release for no apparent reason and nobody seemed to care… but oh man, when they work…
Guided Tours have enormous potential, and one way to show ServiceNow that they’re important to us (and hopefully get them to stop breaking the darn things), is by using them.

The fragility of Guided Tours means that big, complicated, or critical use-cases are probably not advisable; but for situations like this, they’re perfect.
…As long as you’re on a version of ServiceNow that didn’t break them. ಠ_ಠ

In this case, what I’d do is create a Guided Tour called “Incident Activity History Changes”, and make it available only to people who are likely to need to know what’s going on with the activity history on that form and care what fields are selected: itil users.

With Guided Tours, you can even disable auto-launch, but create a corresponding Knowledge Article or form annotation thingy that has a link which directly launches the Guided Tour!

The main down-side to Guided Tours? Well, they don’t… work…
I mean, they do… sometimes.
I’m told that ServiceNow is working on un-breaking them… again… but resolving technical debt and fixing core functionality that they’ve broken has never really been ServiceNow’s strong suit, y’know?

Pro-tip for Guided Tours: Whenever your next “step” is on an element or control which may or may not exist depending on the user’s persona or permissions, consider making that (and perhaps a chunk of following related steps) be skippable so that the tour doesn’t automatically bail out the moment it hits a step tagged to an element that the user might not see. You can sometimes even go so far as to create whole skippable error-handling paths within your Guided Tours but since Guided Tours are highly linear, that is very rarely worth the extra work.
Just remember to always test your Guided Tours as different user personas, the same way you’d test any other functionality you build!

Conveyance

A big part of User Experience (UX) design is “conveyance”: the seamless and intuitive flow of information and guidance relating to the user’s journey to achieve whatever goal they’re aiming for as they use your fancy-fresh app.
Think of conveyance as representing how well your app’s UI communicates what an interface or element element does, how to interact with it, and what the result of that interaction will be. It's about making the function and purpose of elements clear intuitively, without requiring too much explanation.

Effective UX conveyance consists of a whole bunch of complicated ideas that can be hard to describe in writing, and largely come down to intuition and the developer’s ability to imagine the perspective of a user who is new to their application… so rather than try to explain UX conveyance in words, I’m going to outsource the job to my two favorite YouTube videos on the topic:

Good Conveyance: Mega Man X

Bad Conveyance: Dr. Jekyll & Mr. Hyde