Best approach to implement an OOB Workspace?

[Jen Hu]

Hi there,

We are looking to operationalize an OOB workspace.  There are some areas where configuration options are not available.  For example, if we would like to add/remove containers/components on the Home > "Overview" or Record "Overview" page to show what's important to the business rather than the defaults, what would be the best approach?

a) Clone the page / create a page variant and add/remove the containers/components we'd like to show on the page variant.  If we go with this option.  It copies all the associated UX Client Scripts, Events, Macroponent Definitions, etc.  What happens on upgrade if there are any updates made to the scripts /api calls?  Since our cloned page won't get updates, will our cloned page and scripts have a chance of breaking when the OOB Workspace got updates or have updates to scripts?   What are the chances of that happening?

b) Modify the OOB page directly in place. Again, on OOB workspace updates, our modified UX Macroponent Definition (and perhaps other related UX configs) will be marked as a Skipped Change and we will have to review the skipped changes if there's any updates from ServiceNow.

c) Create a totally custom Experience.  If we go with this approach, we may not able to receive benefits from the specific OOB workspace features.  It may be also more time consuming to set up the custom workspace from scratch?

How have your implemented an OOB workspace and any recommendation on how to make it easily configurable, meeting business needs, and easily maintainable with upgrades?

Thoughts?  Any suggestions is welcome!

Thanks,
Jenny

[anand-bhosle]

Hello @Jen Hu.

1. Option A: Clone the OOB Page (Create a Page Variant)

How it works

• In UI Builder you “Copy” the delivered page into your own scoped app.

• You then add/remove containers, drag in your components, and tweak properties.

Pros

• Full freedom to reorder or remove any container or macro-component.

• You can rename or repurpose your copy without impacting other teams.

Cons & Upgrade Impact

• No automatic merges. Your clone lives in your scope, so any change ServiceNow makes to the original page will not flow into your copy.

• UX client scripts, events, macro-component definitions, data-providers: they’re all duplicated at the point of cloning. If SN delivers an enhancement or bug fix to one of those pieces, you must manually reconcile that change into your clone.

• Risk of drift. Over multiple releases, the two pages diverge; resolving merge conflicts can become labor-intensive.

Chance of breaking

• Low–moderate for minor API tweaks. If ServiceNow only adds a new parameter or fixes a rendering bug in the core macro-component, your cloned variant still points at the same code, so you’ll automatically get that fix (unless they rename or remove the API).

• Higher for structural changes. If they redesign how a macro-component “OverviewList” sources its data or remove fields your clone relied on, you could see rendering errors until you patch your variant.
  
  

  2. Option B: Build a Completely Custom Experience

  How it works

  • Start from a blank Now-Experience project. Build pages, containers, and components from scratch (or reuse community-built ones).

  Pros

  • Total design freedom. You’re not constrained by the delivered UX layer or data-model assumptions.

  • No “merge pain” with OOB pages—your codebase lives entirely in your own app.

  Cons & Trade-offs

  • Reinventing common features. You’ll need to rebuild search, breadcrumbs, record context menus, tabs, timeline widgets, etc., or find publicly-available packages.

  • Longer time to market. A full workspace framework can take weeks of engineering vs. hours to variant an OOB page.

  • Loss of guided experience. New hires or admins familiar with the OOB layout have to learn your bespoke screens.
    
    Buttom line suggestion is Option A (Page Variants) strikes the best balance of flexibility and maintainability for most teams. You get exactly the layout your users need, while still inheriting underlying API and data-provider improvements. By combining variants with a lightweight custom component library and an automated upgrade-review process, you can keep your workspace tailored to business needs and resilient across ServiceNow releases.
    Customization is like you break it you bought it 🙂 all the best

If you think I answered your questions, please mark helpful/accepted

Thank You

Anand

[Brad Tilton · Accepted solution]

Option 1, duplicating the page into a new variant, is our recommended best practice. On the back-end everything is stored in JSON in the macroponent record so the only additional records outside of the macroponent that actually get created are the client script records, and those would be duplicates so the page should be safe.

The big downside here is that if the original variant gets updated and you want to take advantage of the new updates you'll need to do that manually either reduplicating the original page or building that functionality into your new page.