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.
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 10-vehicle bay for complimentary car washes offered monthly to employees. The customer had already built a custom scoped application to manage the schedule for the 10 bays and wanted to display real-time bay availability and an employee's next scheduled wash on their portal's homepage. All the data existed on their ServiceNow instance, and they just needed a way to display it to the user.
Since ServiceNow does not offer a car wash product, we did not have a widget that met their needs. Using the GIideRecord APIs and some creative HTML and CSS, our team built a simple widget to highlight the information mentioned above. The impact on the employee experience of making it easier for employees to take advantage of this benefit was positive, and the technical debt risk was low. It was a no brainer for this client to implement the concept.
What does it take to do this well?
There are two factors that are critical to making the right decisions about UI objects to meet your user needs and business goals.
#1 - Develop a good understanding of your users, their needs, and their behaviors.
Your team should be using human-centered design techniques to develop personas, journey maps, and shared understanding of how your users will interact with your solution. This research and alignment will help you articulate why a unique UI customization is needed and the benefit to the users. Without these data it is just one person's opinion against another, and technical debt sounds scary to stakeholders.
Maintaining accessibility
ServiceNow strives to make our products WCAG 2.1 AA conformant. This includes the Service Portal framework and the Employee Center implementation of portal. When you create your own UI objects, you should conduct an accessibility assessment like the Voluntary Product Accessibility Template (VPAT) to ensure your modifications maintain conformance.
#2 - Hire/contract the right skills onto your delivery team
Delivering custom UI objects requires a different skill set than what the traditional ServiceNow admin or developer may have. Both Service Portal and the Next Experience UI framework use modern web tech stacks that are common in the developer community. Fortunately, these skills are easy to find in the general labor supply.
According to the Stack Overflow Developer Survey 2022 JavaScript is the most popular language (10th year running). React.JS is the 2nd most popular web framework (Next Experience UI framework is React-like) and Angular is the 5th most popular (Service Portal and Employee Center are built on Angular).
Our experience shows that pairing folks skilled in these frameworks with a seasoned ServiceNow developer can have an immediate positive impact on your implementation.
How do you think about UI customizations?
In summary, UI object customizations may be critical to the success of your solution on ServiceNow. With good understanding of your users, a focus on business outcomes, and the right resources you can make smart decisions for when customization makes sense for your business.
We want to hear from you! How does your company decide when to implement custom UI objects? How do you evaluate the value vs. the complexity? Let us know in the comments.
