Unlocking Efficiency: Cross‑Workspace Interoperability in the Now Platform

[Sharon_Barnes]

If you've ever stared at a perfectly configured workspace page and thought "I wish I could just use that over here" — you're not alone. It's one of the most common pain points we hear from admins managing multiple workspaces on the Now Platform. The good news: as of the Zurich release, there's a better way.

This post covers what cross-workspace interoperability is, why it matters, how to set it up (it's faster than you'd expect), and a few things to keep in mind before you dive in.

The Problem: Duplicate Work, Inconsistent Results

ServiceNow provides dedicated workspaces for different department groups — HR, IT, front office, customer service, and more. That's by design: each team needs a curated, domain-relevant experience. But this structure creates a real challenge when your organization runs several workspaces and you want to share a page between them.

Here's a concrete example: imagine you have a polished Change Request record page in your Service Operations Workspace. Now you need that same page available in your CSM Workspace — because a single change request can affect multiple customers. Until now, your options were limited. There was no native way to clone a page across workspaces. Admins had to manually recreate it, which meant higher maintenance overhead and, inevitably, inconsistencies between the original and the copy.

Multiply that across a large org with several workspaces and several teams iterating on their pages, and you've got a real problem. Teams that have refined their workspace pages over multiple releases shouldn't have to hand off tribal knowledge and hope another team rebuilds it faithfully.

The Solution: Interoperability

Introduced in the Zurich release, cross-workspace interoperability lets admins reuse workspace pages across multiple workspaces — without rebuilding them. You configure a page once, mark it as available across experiences, then add it to any workspace that needs it.

The core benefits:

• Reduced technical overhead. Stop maintaining near-identical copies of the same page in multiple workspaces.
• Preserved domain expertise. When a team has refined a workspace page over several iterations, they can share it with another team — no wheel-reinventing required.
• Easier upgrade management. Once pages are standardized and shared, improvements to the source page can cascade to all workspaces using it.

How to Set It Up

The configuration is short — two main steps. There's a small caveat for Zurich (more on that below), but here's the flow:

Step 1: Enable the page for cross-workspace use

Navigate to the sys_ux_app_route table (you can get there by typing sys_ux_app_route.list in the navigator). Find the page you want to share — for example, the Create Change Request page from Service Operations Workspace. Open the record and check the Use Across Experiences checkbox, then hit Update.

⚠️ Important: Only do this with pages (or variants) that you already own. Checking this box on an out-of-the-box page counts as a customization and could have upgrade implications. For demo purposes, Dexter showed this using an OOTB page — but in practice, use your own variants.

Step 2: Add the page to your target workspace in UI Builder

Open UI Builder and navigate to the workspace where you want to add the page. Click the + button next to Pages. You'll see an Advanced tab — that tab only appears when there are interoperable pages available that aren't already part of the current experience. Click it, then select Add a page from another experience.

From here you can:

• See which pages are available and where they come from
• Review required roles (users in the new workspace will need those roles to access the page)
• Select specific variants if multiple exist
• Set usage criteria, available audience, and conditions

A key thing to remember: because the page is shared, changes made in either workspace affect both. This isn't a copy — it's the same page. That's the power and the responsibility of this feature.

Zurich note: In the current Zurich release, Step 1 requires going directly into the metadata record (outside of UI Builder) because the Use Across Experiences checkbox wasn't exposed in UI Builder in time for the release. That changes with the Australia release — everything will be inside UI Builder, and documentation will be published at that point. For now, the workflow above is the path forward, and it works.

Things to Know Before You Start

Use variants, not out-of-the-box pages

This is worth repeating: interoperability is designed for use with custom variants of pages — not OOTB pages directly. When you create a variant, you own it. Changes you make won't be overwritten during upgrades, and you won't risk catching OOTB records in a customization flag. Assign a developer as the page owner so any changes go through them, especially when that page is shared across workspaces.

Shared pages require change management

Since edits to a shared page affect every workspace using it, you'll want internal documentation and a clear process for who can modify it. This feature tends to be most valuable for larger organizations that already have that kind of governance infrastructure in place — but any team using it should treat shared pages with the same care they'd give shared libraries or services.

The customization vs. configuration tradeoff

The broader workspace ecosystem is navigating a familiar tension: more customization gives teams more power, but more customization also makes it harder for ServiceNow to provide support. Out-of-the-box and configurable experiences are supportable. Heavily customized setups — especially custom CLI components — are largely on the admin to maintain. Interoperability is a configurable feature, which means it sits in the "we can support this" zone. The team is actively looking for feedback on where the right balance is for the future of workspaces.

What's New in UI Builder (Zurich)

Alongside interoperability, the Zurich release also brought a couple of handy UI Builder enhancements worth knowing about:

• Page tagging: Pages can now be tagged to indicate they're interoperable — so it's easy to see at a glance which pages are available for sharing across experiences.
• Page type filtering: You can now filter pages by type (record pages, list pages, landing pages) in UI Builder. As your interoperable workspace footprint grows, this makes it a lot easier to find what you're looking for.

Resources for Learning UI Builder

If you're newer to UI Builder — or want to level up — here's a learning path the team recommends:

• UI Builder 101 by Chris Johnson — Covers the foundational mental model for how UI Builder works, including metadata records, variants, and duplication. (Yes, it has chickens in it.)
• UI Builder Fundamentals course on ServiceNow University — A solid structured starting point.
• UI Builder Advanced course on ServiceNow University — Maria Gabriela helped build this one. You create a custom workspace for an animal shelter and get dog pictures halfway through. Worth it.

Try It Out

Cross-workspace interoperability is available now on Zurich. The full documentation will land alongside the Australia release when the configuration moves entirely into UI Builder — but the feature is working today. If you have a custom workspace page that multiple teams would benefit from, this is a good time to start experimenting.

And if you have feedback on where the workspace customization-vs-configuration balance should land — the team genuinely wants to hear it. Drop your thoughts in the ServiceNow Community.