In many calls we have with customers and partners about how to deliver great experiences or our different UI frameworks the topic of configuration vs. customizations always comes up. For many valid reasons, we emphasize that customers should stick to out of the box as much as possible when implementing our products; it helps your upgrade cycles, and it helps us provide better support. Customization can mean many different things on the ServiceNow platform, and each type has many different implications to your technical debt, upgrade cycle, and user experience. In this article, I will focus mostly on customizations to the user experience and the impact of those choices.
What is configuration?
Applications built on ServiceNow provide numerous ways to configure the users’ experience and the workflows a record might follow. It is expected that you will take advantage of the configuration options to tailor experience to your business and user needs.
Configuration can take the form of changing system settings, changing the layout of a form or list, or using tools like UI Builder or Portal Page Designer to change the layout of a page. Configuration encompasses any tailoring of an experience that does not modify the baseline code of your instance.
What is a customization?
According to this KB article a customization is "any change to code that is part of the baseline install of a ServiceNow instance." Typical customizations include modifications or additions to.:
- Client scripts
- UI actions
- UI scripts
- ACLs
- Business rules
- Service Portal widgets
- Next Experience UI components
Customers may modify these objects to add novel capabilities, introduce new logic, or even limit functionality. In some instances, customers may choose customizations over configuration when they are not aware of the low-code and no-code options available to enhance the user experience. By staying abreast of the latest developments of ServiceNow capabilities like Flow Designer, IntegrationHub, and UI Policies, you may avoid the pitfalls of customization.
To learn more, head over to the Customer Success Center's Customization Best Practices article.
What about UI/UX Customizations?
Our modern UI frameworks were designed with specific intention to allow customers to add additional capabilities through widgets (Service Portal) and components (Next Experience UI framework). Let us call them UI objects in the rest of this post. While creating new UI objects requires the writing of code (JavaScript, HTML, CSS) it should not create the same level of risk as modifying the out of the box scripts and other objects above.
Think of these changes as additive to the platform versus modifying the behavior of the products you implement. They create a level of technical debt, in that you need to test them with each release, but since they are an isolated addition, the likelihood of them disrupting the entire platform or preventing an upgrade is minimal.
Even if you clone an existing widget or component (as our best practices suggest), you can always revert to using the out of the box object if a conflict is introduced. You will want to track what objects you cloned in the event you need to revert.
Caveats to consider when cloning out of the box UI objects.
Many of the out of the box UI objects have a lot of complex logic included in them. Consider the form widget for Service Portal. This widget includes all the logic to interpret catalog item variables into the proper input types while honoring ACLs, UI policies, and other logic. If you clone that widget to say allow for a 3-column form layout, you must maintain all that logic in your widget if ServiceNow makes changes to the underlying system. Now, if your modifications are well documented, you may be able to easily replicate them with each release, but that is additional maintenance you must consider.
What common issues might I encounter with a custom UI object?
- An API call used in your UI object is deprecated in a future release.
- Theming hooks that you use change, and the styling is now incorrect in your custom object.
- New functionality is introduced in a new UI object that replicates the custom work you created.
How should I think about custom UI objects?
Like every decision made with a platform, your team needs to weigh the benefits to the users and business against the risks and costs for maintenance and upgrade. The Best Practices article mentioned earlier provides a framework for evaluating the value against the complexity of any customization. Interestingly, in their complexity score, they do not mention UI objects.
Customization Best Practices - Scoring
Making these decisions effectively requires that someone on your team maintains a comprehensive understanding of the UI objects available from the ServiceNow platform. This requires reviewing the Component Library when working with Next Experience UI framework and the appropriate pages on Docs for the Service Portals you have enabled on your instance. Always consider the out of the box options first.
Service Portal widget documentation
Here are just some of the widget libraries available across some of ServiceNow’s products. This text on the first link defines the mindset for Service Portal widgets, "You can use base system widgets as-is in your Service Portal or clone them to suit your own business needs."
- Service Portal base widgets
- Employee Center widgets
- Content Publishing and Content Experiences widgets
An example to consider
A few years ago, I worked on a project for a major auto manufacturer. They were implementing Employee Center (ESC at the time) and wanted to incorporate a unique employee benefit into their portal. For their headquarters-based employees, they had a
2022 Stack Overflow Developer Survey - Web Frameworks & Technologies
