Best Practice for Cloning GRC Workspace (Custom Shell and using OOB Core Tables)

[desmond_teo]

Hi Community,

We are looking to build a custom GRC/Risk Workspace for specific user personas on an on-prem ServiceNow instance (version: Zurich), without modifying OOB records or disrupting upgrade paths.

The goal is to create a parallel Experience that reads and writes to core GRC tables (sn_risk_risk, sn_grc_issue, etc.), mirrors the standard GRC layout, and resides within a custom application scope. Note that the page variant approach is not viable due to our business and organisational setup.

We have the following questions:

Q1. What is the recommended approach to set up the UX Page Registry and App Shell while maintaining feature parity with standard GRC Workspaces?

Q2. What is the cleanest strategy for transferring UI Builder page variants across Experience scopes (e.g., manual UIB copy/paste vs. duplicating sys_ux_screen records in Platform view)?

Q3. Are there specific UX Page Properties, List Categories, or Data Resources in OOB GRC that are known to break when referenced within a new custom Experience?

Any guidance or insights would be greatly appreciated. Thank you.

[sachinvic]

@desmond_teo 

Hi,

For Zurich, avoid cloning or modifying the OOTB GRC Workspace records directly. Instead, create a separate custom Experience in your application scope and reuse the GRC tables/data through supported data resources.

Recommended approach:

• Create a new UI Builder Experience in the custom application scope.
• Use the appropriate Workspace App Shell rather than copying the OOTB shell.
• Recreate the required GRC pages in the custom Experience and bind the components to the existing GRC data.
• Use page variants where the differences are primarily based on persona or role.
• Keep the custom Experience, pages, and configurations in the custom application scope to reduce upgrade impact.

Avoid manually duplicating sys_ux_screen records as the primary migration approach. Let UI Builder manage the page, variant, screen, and page-definition relationships.

For the migration, also check the dependencies around application scope, roles/user criteria, data resources, client state/context, and page definitions.

The overall approach would be:

OOTB GRC functionality >> Custom Experience >> Custom App Shell >> UI Builder Pages/Variants >> GRC Personas

This gives you a separate UX while keeping the underlying GRC functionality OOTB wherever possible.

Please find ServiceNow documentation below for reference. The document provides step-by-step configuration details for Workspace / Workspace Builder (Search Workspace).

https://www.servicenow.com/docs/r/zurich/application-development/ui-builder/work-experiences.html

[desmond_teo]

Thanks for the advice, sachinvic