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. I think.)
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, as you can see below.

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. It implies that users should still be able to select any of these non-default-filtered fields if they choose to, and have them show back up in the activity history for that user (and only for that user).

I looked into how the activity formatter works a while back, 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.

(This is an insane syntax. I have no idea why ServiceNow chose to do it this way rather than just use a JSON string or something like that, but… alas.)

The actual answer to this question is not actually the point of this article, but I’m going to answer it anyway before I talk about conveyance and change-communication.
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 value 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. These are the things that make a user preference record a “default” preference.
    This this encoded query will identify this default preference for the Incident table:
    name=incident.activity.filter^system=true^userISEMPTY

  3. If you find one, 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? I don’t want to override everyone else’s preferences.”

Those users will not be impacted by this change. Default user preferences only apply to users who do not have their own user-specific preference records. To put it another way, default preferences only apply if the user has not customized their own settings. If a user has ever made any change to what fields show in the activity history for them - even if they changed it right back to that their user preference now matches the default, they will still not be impacted by this change to the default User Preference.

“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. Just remember that if you do that in dev, you’ll have to also manually do it in test and prod as well.

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. So 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?

Not like that!

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 very few people might actually read it. Especially if it went out to everyone, instead of being targeted at the people to whom each change was relevant.

That certainly is one pretty-great option: identifying all impacted users before deleting their preference records, and emailing them something beginning with “You have been impacted by a recent feature-change…” to get their attention, then explaining this cool new functionality and how to restore what they had before if they prefer to.
But, aside from mass-emails, 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!

Eh… sorry for calling you ‘baby’.

Okay, I know, Guided Tours in ServiceNow kinda suck sometimes. They’re incredibly fragile, they don’t work in some situations, they were straight-up just broken in the Vancouver release for no apparent reason and nobody at ServiceNow seemed to me to care for over a year… 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? - so be sure to test any guided tours you build thoroughly, as an account with the persona you expect your users to have, in the UI your users would be using, before pushing them to production.

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!

Another pro-tip: If you find that Guided Tours are just too ‘fragile’ and fail-out in the middle too often, consider simply using the auto-launch functionality (which can be configured to only run through once, and gives users the ability to disable auto-launch if they prefer). You can basically hijack the Guided Tours functionality to, instead of having an actual “tour” run, just direct a user to a brief walkthrough video or KB article instead.

Conveyance

A big part of User Experience (UX) design is “conveyance”: the seamless and intuitive flow of information and guidance on the user’s journey to achieve whatever goal they’re aiming for as they use your fancy-fresh functionality.
Think of conveyance as representing how well your app’s UI communicates what an interface or 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. This isn’t always possible (which is where things like Guided Tours comes in), but

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 conveyance in words, I’m going to outsource the job to my favorite YouTube video on the topic:

Good Conveyance: Mega Man X

Bad Conveyance: Dr. Jekyll & Mr. Hyde