Building user interfaces in ServiceNow comes with a unique set of challenges and opportunities. The platform offers two main tools for UI development: the Service Portal and the more modern Next Experience UI Builder. While each has its strengths, they also introduce distinct complexities for developers to navigate. This blog post explores the key differences between these tools, the challenges they pose, and what developers should keep in mind when working with them.
The Service Portal is built on AngularJS, which allows for dynamic, single-page application (SPA) capabilities. It also uses Bootstrap 3 for responsive design and styling. However, one critical aspect to note is that Bootstrap 3 is automatically loaded with every Service Portal instance, making it an inseparable dependency.
For developers looking to implement modern, sleek designs, this can be more of a hindrance than a benefit. The reliance on Bootstrap 3’s outdated styling conventions often requires extensive CSS overrides just to achieve newer design trends, making customization more cumbersome and time-consuming.
ServiceNow’s use of AngularJS in the Service Portal differs from traditional AngularJS practices. It heavily encapsulates widgets, ensuring they are modular and self-contained. While this approach helps maintain isolated, reusable components, it also introduces certain drawbacks.
In a typical SPA workflow, the process is straightforward: the page loads quickly, displaying basic or skeleton UI elements, and then makes asynchronous API calls to fetch data. The interface updates dynamically as the data arrives, leading to a smooth, responsive user experience.
However, the Service Portal workflow reverses this process. Here’s how it works:
This approach can lead to the perception of slow, lagging page loads because users must wait for the server-side operations to finish before the screen updates. Additionally, when navigating from one page to another, the server code executes before the route activates, which further affects responsiveness and disrupts the smooth, dynamic feel typically expected from SPAs. While there are methods to mitigate these issues, these solutions aren't obvious or set up by default and overlook by ServiceNow deverlopers.
The Next Experience UI Builder is a more recent addition to ServiceNow’s suite of tools, designed to simplify UI creation through a drag-and-drop interface. It allows developers to assemble UIs quickly using pre-built components, as well as custom components developed outside of ServiceNow and integrated into the instance. Since UI Builder is ServiceNow's Next Experience UI Framework that is React-like structure, a knowledgeable of its syntax is essential for those looking to build or extend custom components.
However, one of the current limitations of UI Builder is its focus on creating workspaces primarily for agents, managers, and other personnel who need a tailored view of information and functionalities based on their specific job roles. This means that, for now, UI Builder is not ideally suited for developing customer-facing interfaces. As a result, developers still have to rely on the Service Portal for external-facing UIs, leading to a fragmented experience across different parts of the platform.
This fragmentation presents a significant challenge. While internal users benefit from the modern, streamlined design of Next Experience workspaces, customer-facing applications remain tied to the older Service Portal framework. This dual approach means that developers must be proficient in both AngularJS (for the Service Portal) and ServiceNow's Next Experience UI Framework (for UI Builder). The need to master two different frameworks creates a steep learning curve, increasing the complexity of development and making it harder to maintain consistency across the platform.
Moreover, every pre-built component (and there are a lot of them) in UI Builder requires a strong understanding of its purpose and design to effectively configure and utilize it. Developers need to know how each component functions, what parameters it accepts, and how it can be customized to fit their specific use case. This makes having a solid grasp of the tool essential for building effective interfaces.
The complexity of the UI Builder designer tool further adds to the learning curve. While the drag-and-drop interface aims to streamline the process, understanding how to combine components, configure data sources, and manage interactions can still be challenging, especially for new users.
Furthermore, core UI development skills remain crucial. To be effective with UI Builder, developers need to be familiar with concepts like CSS Flexbox for layout control, as well as event handling (e.g., onLoad, onClick). Without this foundational knowledge, it’s difficult to fully leverage the UI Builder tool, making the transition from traditional ServiceNow development to the new Next Experience framework even steeper.
My goal is to provide a free alternative for building UIs in ServiceNow, combining the best features of both UI Builder and Service Portal. This is an ambitious undertaking, but after months of development and drawing on my experience with ServiceNow, I envision a solution that bridges the gap between these tools.
I aim to redefine how web applications are built on ServiceNow, with a strong focus on the developer experience. By adhering to traditional web development practices that most developers are already familiar with, and adding powerful features to streamline and accelerate the development process, this solution will help developers quickly bootstrap and build web applications more efficiently and intuitively.
This solution is built on the Angular 18 framework as the backbone, with Angular Material for UI components following the Material Design principles. While Angular is utilized, knowledge of Angular or TypeScript is not required; developers can build applications using just JavaScript, HTML, and CSS. That said, while I’ve aimed to keep the learning curve minimal, I’ve chosen to use AlpineJS for handling reactivity, so a basic understanding of its syntax is required.
I look forward to continuing work on this solution and plan to deliver it in the second quarter of 2025. Please be on the lookout for follow-up posts where I will break down and explain the solution in more detail.