How to Roll Out Next Experience

[Ashley Snyder]

 Center of Excellence / Next Experience / How to Roll Out Next Experience

FYI: This article has not been updated or reviewed since the Tokyo release. Use at your discretion, but be advised that these methods may or may not work on later releases.

---

Quick Links

Next Experience Readiness Checker

Next Experience Quick Start Guide

Next Experience Product Documentation

Next Experience FAQ

---

Overview

The Next Experience User Interface was launched in San Diego, and since then, we have received customer inquiries regarding the deployment of Next Experience. This article aims to provide an overview of available methods and considerations for rolling out Next Experience, along with sample code for implementing it on a group basis. Please note that this article does not offer deployment advice. To devise the most suitable approach for your specific situation, we strongly recommend collaborating with your implementation partner or engaging with our Customer Outcomes/Expert Services teams.

Additionally, you can find a link to our new Next Experience Readiness Checker above, which enables you to run scans on your instance to identify any unsupported feature usage. This tool can assist you in making informed decisions regarding the timing of your Next Experience rollout.

Note: Code and Share items are not official ServiceNow product development. ServiceNow is not responsible for the maintenance and support of provided code. The code in this article has been tested in San Diego and Tokyo Demo instances. It is recommended when evaluating this code that is done in a Personal Development Instance or Sandbox instance, and your organization make any adjustments/testing as necessary. This being said, if you do find an issue with the code, please drop a comment so I can fix it.

---

Methods

All Users

One method to roll out Next Experience is to do it for all users at once via the system property glide.ui.polaris.experience. Our product documentation has information on considerations, for a short list:

• Review product documentation, make decisions on unsupported and soon-to-be-deprecated features
• Remediate client-side customizations such as DOM Manipulation
• Perform upgrade and regression testing
• Pilot Next Experience in a sub-production instance with test users
• Send communications and provide training early

While there is some planning and organizational change management wrapped into this method, it reduces the operational burden on your administrator team as they will not have to support two desktop user interfaces, as well as reduces confusion in the user community by aligning them to one interface.

Next Experience User Interface features such as configurable menus, banner announcements, etc. will not be ported to Core UI (UI16).

By Group

This article will provide an example on how to roll out Next Experience by group. Group management is best practice in ServiceNow, as assigning items such as roles or user preferences can be very manual and difficult to manage. You can use this method to allow users to use Next Experience in waves, until you finally decide to cutover completely. It is not recommended as a long term or permanent solution.

There are two out-of-the-box items that need are needed for this method:

1. Set the glide.ui.polaris.experience system property to true
2. System user preference glide.ui.polaris.use set to false, this will set all users to Core UI (UI16) This may be in your instance by default, but it's also in the update set:

Field	Value
Name	glide.ui.polaris.use
Description	Enable Next Experience for all users by default
System	true
User	[leave blank]
Type	string
Value	false

At this point you could manage who can use Next Experience via creating user preferences for users. But it's more manageable to do this via groups if that works for your organization's existing group structure. If not, you could however create a script to set user preferences, and one to remove them:

Example User Preference

Field	Value
Name	glide.ui.polaris.use
Description	Enable Next Experience for all users by default
System	false
User	[sys_id of the user]
Type	string
Value	true

This example is going to use the concept of Group types to allow administrators to select which groups should use Next Experience. This can also be done with a field on the Group table, or using a system property with some modification in the scripting. 

Note: There is an out-of-the-box reference qualifier on the Task table Assignment Group field that checks for Type equals null. Your organization may be using Dictionary Overrides to set reference qualifiers by Type. Evaluate your implementation, this may be a scenario in which using a temporary checkbox field on the Group table may work better for your implementation.

The functionality will work as follows:

1. When a group adds the Next Experience group type, a business rule will run through the group members, and check to see if they have the user preference already, if they do not, then it will create it for them.
2. When a group removes the Next Experience group type, a business rule will run through the group members and check if the user is a part of any other group with the type, if they are not then it will remove the user preference.
3. When a group member is added to a group with the Next Experience group type, a business rule will check to see if they already have the user preference and create it if they do not.
4. When a group member is removed from a group with the Next Experience group type, a business rule will check to see if they are members of any other groups with the type, and if not then their user preference will be removed.

The above steps should not create any duplicate user preferences, but in the case somehow a duplicate preference makes it in (as they do), the removal steps will check for that to keep the table clean. You could also just set the user preference to false in the script instead of deleting it if you wish.

This could be expanded if you manage Group Membership via a Catalog Item or some other method, and allow your Group Managers to control this functionality via a Catalog Item. The Group type also allows for reporting on groups and group members that are using Next Experience versus Core UI if your organization needs insight into that.

I've included a global Update Set [COMMUNITY-Next Experience Group Rollout V1] with the code that can be loaded into a Personal Developer Instance or Sandbox environment, feel free to use it as a guide, as it is meant to be as instance agnostic and as simple as possible. It has been tested on San Diego/Tokyo, and if you find issues or scenarios I didn't account for, please comment. Included in the update set:

Type	Name	Description
Group Type	Next Experience	This is referenced in the scripts, so if you don't use this sys_id make sure you update the Business Rules.
User Preference	glide.ui.polaris.use	This is the system user preference I described above. If the update set puts a duplicate in, just remove it.
Business Rule	Group Add Next Experience Type	On the Group table, checks for the type added.
Business Rule	Group Remove Next Experience Type	On the Group table, checks for the type removed.
Business Rule	Member Add Next Experience Preference	On the Group Member table, checks for users added to Next Experience groups.
Business Rule	Member Remove Next Experience Preference	On the Group Member table, checks for users removed from Next Experience groups.

 

Selective Toggle

 

There are two options for toggling Next Experience back and forth. There is a system property that can be set to allow all users to toggle back and forth. The considerations of doing this is that your administrator team will be supporting two user interfaces.

There's also a Share item by @Christoph Lang that works more selectively and can be rolled out certain roles such as admin. Users will use a module to select which user interface they want to use via a UI Page and will log out/in for the changes to take effect. This is a better solution for your administrator teams who still need to use features such as JavaScript Log/Field Watcher, or for users who need access to unsupported features.

[Christoph Lang]

Very nice overview. Thanks for sharing!

[Mark A_ Miller]

@Ashley Snyder I nominate you to be in charge of writing all ServiceNow docs. This is actually helpful! Thanks.

[Susie W]

Great article, thank you.

Just to make you aware, the link to the Next Experience Readiness Checker in the quick links at the top goes to a "This version has been withdrawn from store" page.  I did find another version in the store though.

[MGOPW]

@Susie W - Thank you very much! I have updated the link in the main post.

[Ravi Chandra_K]

This is very helpful @Ashley Snyder , Great Work!!! 

[Jim Coyne]

The link is outdated once again because of a newer version of "Next Experience Readiness Checker" in the Store.  Whenever you link to a Store app, DO NOT include the version at the end of the URL.  This will then show the most current version.  Unless, of course, you need to specify a particular version, which would normally be rare.

So, use this:

https://store.servicenow.com/sn_appstore_store.do#!/store/application/ad298cb6d4334378b8744c55ab9214...   (notice there is NO version)

...instead of this:

https://store.servicenow.com/sn_appstore_store.do#!/store/application/ad298cb6d4334378b8744c55ab9214...  (specifies a particular version, 23.0.8 in this case)

[Dibya Sarkar009]

System user preference glide.ui.polaris.use set to false, this will set all users to Core UI (UI16) . This is not working in Vancouver patch 3 . Is there any issue regarding this ?

[northfdl54937]

Not working for me either...