ServiceNow UI Builder and Workspaces: Security and Access Design

This guide covers how to control access to ServiceNow UI Builder workspaces and to the records they display. It covers role models, least privilege, row-level security, permission checks before sensitive actions, audit trails, testing, and data retention at decommissioning.

Role Model for Workspace Data Access

Workspaces built in UI Builder often expose business-sensitive data: HR case details, financial records, security incidents, customer information. Data access must be controlled at multiple levels. Application-level access prevents users from viewing workspaces they should not see (a finance employee should not see the HR workspace). Data-level access prevents users from viewing records they should not see (an HR analyst can see cases for their business unit but not other business units). The Workspace Owner decides who has access to the workspace and what data should be visible to each user group. The Platform Administrator configures the access controls in ServiceNow (roles, workspace access, record filters). The Data Governance Team defines data classification and which users are authorized to see sensitive data. The Application Developer implements row-level security filters in UI pages to enforce the data classification rules.

Least Privilege and Data Segregation

Grant workspace access narrowly tied to user role and business context. A customer service representative in the US region should see only customer cases from the US region, not global cases. Implement this through record ownership fields and business context filters, not by creating separate workspaces for each region. If a UI page contains data from multiple tables (incident, change, CMDB), ensure that row-level security is applied to all tables so users cannot see data they lack permission to access. For example, an incident details page should not display CMDB records that the user cannot read directly; if the incident is linked to a CI, the UI page should show only CI information the user has access to, or hide the CI link entirely.

Sensitive operations (deleting records, modifying security configurations, approving high-value requests) should require explicit permission checks before the UI page allows the action. A UI form that allows someone to change a user’s access level should check permissions before submitting the change; this prevents accidentally granting permissions through UI manipulation if access controls are misconfigured. Test this explicitly: as a low-privilege test user, attempt to perform sensitive operations and confirm that the UI prevents the action and logs the attempt.

Audit Logging and Access Trails

Enable audit logging for all workspace administration actions: who created or modified a workspace, who updated workspace access, who published a UI page. If a workspace configuration is accidentally changed and causes users to lose access to data they need, audit logs allow the Administrator to determine what happened and when. Audit logs should also track data access: which users viewed which records, when, and for how long. This audit trail supports compliance investigations if sensitive data access needs to be verified or if unauthorized access is suspected. Maintain audit logs for the period set by applicable regulatory requirements to support regulatory reviews.

For workspaces containing highly sensitive data (security incidents, financial details, employee records), implement additional logging: log failed access attempts (user tried to view a record they lack permission to see), log unusual access patterns (user accessing data outside normal business hours or accessing significantly more records than typical), and alert administrators to potential data abuse. This early warning system can catch unauthorized access before large amounts of data are exposed.

Testing Data Access Controls

Before publishing a UI page with row-level security, test access controls explicitly. Create multiple test users with different roles and business contexts; verify that each user sees only the data they should see. A test with full-access admin accounts passing does not validate that row-level security works; use low-privilege test accounts. For example, create a test incident and verify that only the assigned team can see it. Create a test financial record and verify that only authorized financial analysts can see it. A test case for each data classification level (public, internal, confidential, restricted) ensures that access controls work as designed across the security spectrum.

Data Retention and Workspace Decommissioning

When a workspace is decommissioned (no longer needed), decide what happens to data it contained. If the workspace was a prototype or temporary initiative, archive the underlying data for audit purposes but do not keep the workspace accessible. If the workspace was operational and contained production data, ensure the data is migrated or archived before the workspace is deleted. A workspace should never be deleted without explicit approval from the Workspace Owner and confirmation that data migration is complete and verified.

How data reaches the page and under whose identity

The first question is which identity a piece of data is read under. A data resource that queries a table from the browser runs in the signed-in user’s context, so the table’s access control rules apply to every row that user can reach. A server-side endpoint may run under a broader service identity, which means its own code has to enforce the filter the user should see. Much unexpected exposure comes from the second case: a convenient endpoint returns a full table because the developer tested it with an administrator account and never tried it as an ordinary user.

Where exposure actually happens

A review sequence for each sensitive page

1. Sign in as one test user from each role the page is visible to, and record exactly which rows and fields appear.
2. Call the server endpoint directly with an ordinary user session, without the page, and compare the response with what the page showed.
3. Check that every filter is enforced in server logic, not only in the page layer.
4. Confirm that the audit trail records create, update and delete activity on the underlying tables.
5. Ask the data owner to sign the list of fields the page exposes, and keep that signature with the release record.

Auditing administration of workspaces

Audit logging for the workspace itself covers who created or changed a page, who altered its role assignments and who published a new version. Those records are only useful if someone reads them. Set a monthly review for pages that carry sensitive data and a quarterly review for the rest. Look for role grants that appeared without a matching request, and for publish events that fall outside the change calendar, since both often indicate a shortcut that was never recorded.

When to keep data out of a workspace

A few categories should remain on a classic form with stricter controls. Investigation records under legal hold, detailed compensation data and security incident notes that name individual sources often carry rules a flexible page cannot express cleanly. A workspace that shows a summary, with a route back to the protected record, can serve most users while the detail stays where the controls were designed for it.

Checklist before granting access to a workspace

• The data owner has approved each table and field the workspace reads.
• Every server endpoint validates its input and applies the requesting user’s own filter.
• No credential, token or key appears in any page property or component setting.
• Guest or unauthenticated access is off unless a named owner has approved the exposed content.
• Test results for at least one user per role are stored with the release record.

Questions about securing workspace data

If the table rules are correct, is the page automatically safe?

No. Table rules protect the rows, but they do not stop a page from displaying a computed field, combining data in a way the owner did not intend, or exporting a list the user should only see in summary. Test the page as a user would experience it, not only the table behind it.

Should a service account be allowed to read everything for convenience?

It should read what its endpoint needs and no more. A broad service identity turns every endpoint defect into a full-table exposure. Scope it to the tables and operations each integration uses, and review those grants whenever the integration changes.

What do we do about a demonstration page that is still live?

Treat it as a live exposure. Restrict the access settings first, then review what the page displayed and to whom, using the audit trail and access logs as the record. The owner decides whether the event needs reporting under the organization’s own policy, and that decision should be written down either way.

How often should role assignments on a workspace be reviewed?

More often than the pages themselves change. Role grants tend to accumulate, because each request is approved on its own merits and nobody looks at the total. A review tied to the access recertification cycle can catch drift before it becomes a finding.

Next step

The access controls review notes and the integration patterns for these pages cover the access and integration side of this topic.