ServiceNow UI Builder Page Explained

What is a UI Builder Page

A UI Builder page is a custom interface created with the UI Builder tool in ServiceNow. Instead of writing HTML or JavaScript code, you drag components such as cards, tables, buttons, input fields, charts, and text elements onto a canvas and configure their behavior through a visual interface. Pages can display data from multiple tables simultaneously, filter and sort records based on user input, trigger server-side actions when buttons are clicked, and provide validation for user entries. They run in a web browser and deliver a modern, responsive user experience without requiring developers to write code. UI Builder pages are increasingly used to replace custom portals or external reporting tools.

Where UI Builder Pages Live in the Platform

Pages created in UI Builder are stored in the UI Builder Packages table and also referenced in the UI Pages table. Each page has a unique ID and URL path that users can navigate to or access through bookmarks and menu items. Pages can be published to your instance with varying access levels: you can restrict access to specific roles, specific groups, or make them publicly available to all users. The UI Builder editor interface shows a canvas on the left where you compose the page, a component palette on the right showing available UI elements, and a data source panel where you define what information the page displays and how updates are processed. Pages support versioning, allowing you to make changes without affecting users until you publish a new version.

Key Differences Between Pages and Forms

A ServiceNow form displays and edits a single record from a table and is typically accessed by clicking on that record in a list. A UI Builder page can display data from multiple tables in a single view, show aggregated information or computed values, support complex workflows that span multiple records, and include visualization elements that forms do not support, such as custom dashboards, charts, or kanban boards. Pages are designed for user journeys that require interaction with several records or need to pull data from external sources, whereas forms focus on the task of entering or editing one record at a time. Pages also support more complex navigation patterns and conditional layouts.

Building a Simple Page

Creating a basic page involves dragging a Table component onto the canvas and connecting it to a data source that queries a ServiceNow table. You configure which columns appear in the table and add sorting or filtering. You then add a button that, when clicked, opens a dialog form for creating a new record, or you add a Text component that displays computed values based on filtered data. Pages support conditional rendering, which means a section of the page only appears if certain conditions are met, such as the user’s role or a field value in the displayed data. You can also add scripts to handle complex interactions. Many organisations start with a simple page that displays records in a table and gradually add advanced features.

Design Considerations for Production Pages

When planning a UI page, decide whether you need real-time updates or if periodic data refresh is acceptable. Consider how many records the page must display; loading thousands of rows into a table component can impact performance and browser memory usage. Plan for empty states—what message should appear if no data matches the filters so users understand that the page is working correctly. Ensure the page layout works on mobile devices by using responsive components and testing on different screen sizes. Also consider data security: ensure that components and data sources respect table-level and field-level security rules so users see only data they are authorized to access. Performance testing before production deployment is recommended.

Advanced Features and Integration Options

Pages can be integrated with workflows, so clicking a button on a page can trigger a multi-step approval process or data transformation. Pages can also subscribe to updates from other pages or components, allowing you to build dashboards where selections on one page filter data on another. You can embed pages within other pages to create modular designs. Pages support theming and custom CSS, allowing you to match your organization’s visual identity. Some advanced use cases include building custom procurement interfaces, project tracking dashboards, or complex data migration tools.

Deciding between a UI Builder page, a list and a workspace

The first question is whether the user needs to see several records at once, or to act on one record with context from others. A filtered list answers the first need with little effort. A form answers the second when the context lives on the record itself. A UI Builder page is worth building when the task spans records, needs a layout no standard view offers, or must present a summary that no single table can show. If none of those is true, the page adds a surface to maintain without giving the user anything new.

Workspace layouts are covered in the UI Builder and workspaces guide, and the design of agent-facing layouts is discussed in the agent workspace design article.

Ownership, versions and access before the first publish

Every UI Builder page needs a named owner who can say which records it shows, which role should see it, and what users do if it is unavailable. Grant access by role rather than by named user. Set up test identities first, one for each persona that will use the page, and check the page as each of them. A page that looks right to an administrator can show empty tables to an agent whose access control lists exclude one field the page depends on.

Use the page’s versioning deliberately. Keep a short note with each published version listing the data sources changed, the components added and the roles affected. When a change goes wrong, that note tells the owner which version to republish, so nobody has to reconstruct the change from memory.

Test order for a page that will carry real work

1. Confirm each data source returns the expected records for one test identity, before adding any component that displays them.
2. Check the empty state for every table and summary, using a filter that matches nothing, and read the message as a user would.
3. Repeat the same checks for each persona, looking for fields or actions that disappear without an explanation.
4. Load the page with the largest realistic volume the business expects, and watch responsiveness on a standard work laptop as well as on a phone.
5. Run each button that writes data against a test record, then confirm the change in the underlying table and in any downstream workflow.

Performance and volume limits that surface late

A page can feel fast in the builder and slow in production, because the builder loads a small sample. Large tables, unfiltered data sources and summaries that recalculate on every keystroke are common causes. Filter on the server before data reaches the browser, and load summaries as separate, smaller queries rather than one query that joins everything. If a page needs a dataset that is genuinely large, ask whether a report or a dashboard on a scheduled refresh answers the question better. The platform performance guide is the reference for diagnosing slow loads.

Real-time updates are another trap. Subscribing to changes sounds attractive, but a page that refreshes every few seconds for many users adds load and distracts the people using it. Ask what decision the user makes from the freshness of the data. If the answer is a periodic review, a manual refresh control is enough.

Telling whether the page is delivering value

A page is working when users stop asking for an export of its data to a spreadsheet, when the records they act on are the ones the page shows, and when support requests about the page fall after the first month. Warning signs are users who open the page once and go back to the list, and two teams building parallel pages for the same task. Track those signals with a short user survey, and check which pages the team’s reports and dashboards actually reference, because usage data is more honest than a feedback form.

Questions owners raise after launch

Can a UI Builder page replace a custom portal entirely?

For some journeys, yes. Where the portal carries unusual branding, public access or content that is not record-driven, it may still be the better home. Map each journey to a page type before retiring anything.

What should happen when a data source is slow or unavailable?

Design the component to show a clear message and a retry control rather than an empty table. Users read an empty table as a fact about the data, which is a worse outcome than an honest error.

Who may edit a published page?

A small group, working in a copy and promoting changes through the normal update set process. Editing a live page directly can leave users looking at a half-finished layout.

Does a page need to match the rest of the instance visually?

Match the colors and spacing of the instance’s standard components where you can. A page that looks like a different product makes users wonder whether they are in the right place.

Next step

When a team is planning several pages at once, a short review of which tasks need a page, which need a list and which need neither saves rebuilding later.