ServiceNow UI Builder and Workspaces: Roles, Responsibilities and RACI

This guide sets out who does what in UI Builder and Workspaces. It covers the UI application developer, UX designer, workspace owner, platform administrator, component developer and IT architect, and includes a RACI matrix for each activity. It also makes clear who decides which pages are published and who can access them.

UI Builder and Workspace Development Roles

UI Builder and Workspaces represent a shift in ServiceNow development from traditional form-based configuration to modern component-based interfaces. The UI Application Developer builds UI pages using UI Builder components: lists, forms, cards, charts, and custom components. The UX Designer specifies interface wireframes, interaction patterns, and usability requirements before development; they ensure the UI is intuitive for target users. The Workspace Owner is typically a business manager or IT director who owns a workspace (a curated collection of UI pages and configurations); they decide which UI pages are published to which user groups. The Platform Administrator manages workspace settings, user access to workspaces, and integration with the underlying data platform. The Component Developer creates custom UI Builder components when out-of-the-box components do not meet requirements, either in the low-code Component Builder or in code with the Next Experience UI Framework and the ServiceNow command-line tools. The IT Architect sets workspace strategy: which business processes should be redesigned with UI Builder, what standards and patterns should be used, and how workspaces integrate with ITSM and other modules.

Workspace Ownership and Access Governance

The Workspace Owner makes decisions about which UI pages are published in their workspace and who can access them. A workspace for IT operations differs from a workspace for human resources; each owner decides what their workspace contains. The Platform Administrator configures access controls: which users or groups can access which workspaces. A service desk manager’s workspace shows service desk work; a CFO’s workspace shows financial dashboards and approval tasks. The UX Designer and Application Developer report to the Workspace Owner on design and development progress; they do not make scope or access decisions independently. If a UI page needs to be moved from one workspace to another, the Workspace Owners of both workspaces must agree; the Platform Administrator executes the move.

RACI Matrix for UI Builder and Workspace Activities

The following table clarifies responsibilities across UI workspace activities:

Component Reuse and Design Standards

The IT Architect establishes UI Builder design standards so that workspaces feel cohesive: standard color palettes, font sizes, button styles, and layout patterns. Application Developers follow these standards when building UI pages so that users moving between workspaces encounter consistent interfaces. If a standard component does not meet a specific need, the Component Developer creates a custom component, which is added to a shared library and reused by other workspaces. This prevents teams from building equivalent components independently, which wastes effort and creates inconsistent interfaces. The IT Architect reviews new custom components before they are added to the shared library to ensure they follow standards and do not duplicate existing components.

Workspace Governance and Change Control

Major UI changes (redesigning a core workflow, significantly changing the workspace structure) should be tested with representatives from the target user group before deployment. The Workspace Owner approves test plans and review findings. If usability testing identifies usability issues, the Application Developer and UX Designer adjust the design and re-test before publishing to production. The Platform Administrator applies access controls to UI pages so that they are visible only to appropriate users; if a page contains sensitive data or processes restricted by policy, row-level security and role-based visibility must be configured and tested. A quarterly workspace review brings together the Workspace Owner, Application Developers, UX Designer, and Platform Administrator to assess workspace health: are users adopting the workspace? Are there usability complaints? Are there performance issues? Findings from the review drive improvements for the next quarter.

Workspace Performance and Scalability

UI pages built in UI Builder should be tested with realistic data loads. A list showing 100,000 records may perform poorly if pagination is not correctly configured. The Application Developer should test UI pages with data volumes expected in production and confirm that response times meet user expectations. If performance is inadequate, the developer may need to add filtering or change the data source to a summarized table that pre-aggregates data. The Platform Administrator monitors workspace performance in production and alerts the Application Developer to performance regressions after deployments.

Decision rights that a responsibility matrix does not capture

A responsibility matrix tells you who does the work. It rarely says who may stop a release, who can grant access to a new group, or who decides that a page is retired. Those decision rights are where workspaces stall. Write them as a separate short table, one row per decision, with one accountable role for each row. When the table is missing, the same argument is held again for every page.

Onboarding a new page builder

1. Confirm the builder’s platform role and the workspaces they may edit. Avoid granting edit rights across the whole instance by default.
2. Walk through the naming standard for pages, components and data resources, and show an example of a name that was rejected and why.
3. Assign a reviewer who will check the first two pages before they publish.
4. Give the builder a sandbox copy of a real page to change, rather than live content.
5. Record the first publish date and the reviewer’s sign-off in the workspace record.

Handover between build and operations

The handover is where ownership often breaks. The build team knows why a binding points at a particular table. Operations knows when a user reports a blank panel late in the evening. Neither helps the other unless the handover includes a short operations guide: the owner of each data source, the alerts that exist, the known limits, and the steps to pause a page without calling a developer. Run a walkthrough with the on-call group and have them perform one pause and one restore in a test environment before the page goes live.

Where ownership usually goes wrong

Three gaps appear often. A page is owned by a project that closes, and nobody takes over its content. A shared component is changed by one builder because the change was convenient, and the pages that depend on it break without warning. Access grants accumulate because each request was approved locally and nobody reviews the total. Periodic access reviews and a component register that names the dependent pages can close these gaps at modest cost. The access review should include the service accounts that pages rely on, because a retired page can leave a live grant behind.

A useful test for ownership is to ask who would be paged at two in the morning if the page failed, and whether that person could find the page’s data sources without help from the original builder.

Questions about workspace roles

Can the page owner also be the builder?

In a small team, often yes. The approval for a publish should still come from someone who did not make the change. Separation matters most for pages that touch sensitive data or that users rely on for regulated work.

How many people should be able to publish to a live workspace?

Keep the number small enough that every publish has a clear approver, and widen it only when the review queue shows no delay. The right number depends on team size and release frequency, so review it after the first few cycles rather than fixing it in advance.

Who speaks for the business when a page needs a change?

The workspace owner holds the business requirement, and the builder holds the technical options. Builders should bring the options together with their effects on users and on maintenance, and the owner chooses between them. A builder who makes that choice alone is taking on a decision that belongs to someone else.

What should happen when the page owner leaves the organization?

The ownership record should name a successor before the departure date, and the successor should walk the page with the builder. An unowned page is not a neutral state. It tends to stop receiving fixes, keeps its access grants, and eventually breaks on a platform change that nobody is positioned to handle.

Next step

The governance model for these workspaces is the natural place to record the outcome.