ServiceNow UI Builder and Workspaces: Guides and Services

What UI Builder Provides

UI Builder is a low-code interface design tool that allows organisations to build modern, mobile-responsive user interfaces without writing code. Pages built in UI Builder use drag-and-drop components to display data, collect input, and trigger actions. The builder produces web applications that run on the Now Platform and integrate natively with ServiceNow tables and data sources.

Workspaces provide a container for UI Builder apps organised by purpose. An IT Operations workspace might contain pages for incident management, service map visualisation, and monitoring dashboards. A Field Service workspace might contain pages for technician work assignment and status updates. Workspaces help organise related applications and simplify navigation for users.

UI Builder Components and Data Integration

The UI Builder component library includes tables, cards, forms, maps, charts, and other interface elements. Components are configured to read data from ServiceNow tables, external APIs, or other data sources. When a user interacts with a component—selecting a row, entering filter values, clicking a button—the interface can trigger actions like updating records, calling workflows, or navigating to another page.

Components support data binding so changes in one component are automatically reflected in others. A filter component can drive data shown in a table; selecting a record in the table can populate details in a side panel. This provides an interactive, responsive experience without requiring code.

Responsive Design and Mobile Support

UI Builder applications are responsive by default and adapt to different screen sizes. A page designed on desktop automatically reflows on tablet or mobile devices. Components have mobile-optimised interaction patterns so mobile users interact with data efficiently on small screens without excessive scrolling or zooming.

UI Builder supports PWA (Progressive Web App) capabilities, allowing applications to work offline and cache data locally, which is valuable for field workers who may not have constant connectivity. Offline applications can queue actions when offline and sync when connectivity is restored.

Performance and Security

Applications built in UI Builder are deployed on the Now Platform and inherit the platform’s security model. Role-based access control applies automatically so users only see data they are authorised to access. Applications can be published to public portals or kept internal to the organisation.

UI Builder applications are optimised for performance and can handle large datasets. However, applications that retrieve very large result sets or run complex calculations should be optimised to avoid browser performance degradation. Data pagination and filtering improve responsiveness.

Common Use Cases

Service portal applications can be rebuilt with UI Builder to provide a more modern look and feel and easier navigation. Operational dashboards display key metrics and allow users to filter, drill into detail, and take action on items shown. Agent interfaces for ITSM or CSM teams provide guided workflows for case handling or incident response. Mobile-first applications for field workers display work assignments, allow status updates, and capture photos or signatures.

Integration With ServiceNow Modules

UI Builder applications integrate with ITSM modules through data binding to incident, change, and request records. CSM applications display cases and customer information. Reporting dashboards pull data from Performance Analytics or custom reporting tables. Workflow integration allows UI Builder actions to trigger Flow Designer workflows or Integration Hub integrations automatically.

Oblytech’s UI Builder Services

We design UI Builder interfaces to match customer workflows and user needs. Implementation includes planning the page structure, configuring data sources, building responsive layouts, and integrating with backend workflows. We also modernise existing service portal applications by rebuilding them in UI Builder with improved navigation and mobile support.

Publishing and Versioning UI Builder Applications

UI Builder applications are published to URLs that can be shared or embedded in other portals. Versioning allows applications to evolve while users continue working. Changes can be staged and tested before being published to production.

Accessibility and User Experience

UI Builder applications should be accessible to all users including those with visual or mobility impairments. Components can be configured for keyboard navigation and screen reader support. User testing with diverse user groups identifies accessibility gaps.

Choosing between a workspace, a portal page and a classic form

The question most buyers face is not whether UI Builder can build a screen, because it almost always can. The question is whether the screen will earn its maintenance cost. A single data-entry form that three people use a month rarely justifies a new workspace. A console that an operations team opens all day, with a queue, a detail panel and actions on each item, usually does. The comparison that follows offers a starting point for that judgment, not a rule.

What a workspace has to do to justify itself

A workspace earns its place when it removes a specific piece of work from a specific group of people. Write that sentence before any design begins: which group, which task, and how many times a day it happens. If the sentence cannot be written, the workspace will become a second copy of an existing view, and users will go back to the view they already know. Reference the existing classic views the team uses now, and state which of their steps the workspace removes.

Where UI Builder fits in the wider low-code estate

UI Builder sits alongside workflow, Flow Designer and the other low-code tools on the platform. It is responsible for the screen. The logic behind a button, the approval it starts and the record it updates usually live in the platform’s workflow and business logic, and the screen calls them. Keeping that separation clear makes a workspace easier to change, because a design revision does not risk the business rules underneath it. The page on how a UI Builder page is structured describes the building blocks in more detail.

A short procedure for deciding whether to build

1. Write the one-sentence purpose: the group of users, the task and the frequency.
2. Identify the classic view or portal page that group uses today, and list the steps they take in it.
3. Count how many of those steps a workspace would remove, and name the ones it would not.
4. Check the data sources the screen needs and confirm that the people who will use it already have access to them.
5. Decide who owns the workspace after release, including who approves changes to it.
6. If the count in step three is small and no owner is named, keep the classic view and revisit in a few months.

When a workspace is the wrong answer

A workspace is the wrong answer when the underlying process is still changing every month. Building a polished screen over an unstable process means rebuilding the screen with each change, and users notice the churn long before they notice the polish. It is also the wrong answer when the group that would use it has no sponsor willing to change their routine. A workspace that nobody is asked to use is usually ignored.

Testing the decision against a shortlist

The decision is easier to make with a clear list of candidate screens, the steps each group takes today and an honest view of who will maintain the result. Those three things are usually enough to tell whether UI Builder is the right tool for a given screen.

Questions people ask before committing

Can we move a whole portal to UI Builder in one step?

That is rarely the sensible route. Move the screens with the clearest return first, keep the rest where they are, and treat the two environments as coexisting for a period. A big-bang move concentrates every risk into one release.

Do workspaces need a separate design system?

They need a shared set of components, colors and navigation patterns, so that one workspace does not look like it belongs to a different product. Whether that set is formal or informal matters less than whether two teams can build from the same starting point. The common mistakes page for these workspaces covers the usual errors in building them.

Who should be allowed to build a workspace?

People trained on the platform’s security and data model, with a reviewer who understands the business task. Allowing anyone to publish a screen to a shared audience tends to produce overlapping screens quickly. Clear build rights and a review step are covered in a guide to governing low-code development.

What does it cost to keep a workspace current?

The cost is mostly ongoing attention: reviewing usage, handling requests for changes and retiring screens that nobody opens. Build cost is the smaller part of the total, so the maintenance commitment should be agreed before the build is approved.