Question on Managing Workspace Page Customizations Across Upgrades

[Yamini_Kethe_24]

Hi All,

I would like to better understand the recommended approach for handling Workspace page customizations during upgrades.

In our case, the OOTB Case SRP page is protected, so to implement customizations we duplicated the OOTB page variant and applied our changes to the duplicated variant.

My understanding is that when a ServiceNow upgrade occurs, any new features or enhancements delivered by ServiceNow will be applied to the original OOTB page and not automatically to our duplicated variant.

Is that correct?

If so, after each upgrade, is the expected approach to:

1. Compare the upgraded OOTB variant with our customized variant?
2. Duplicate the latest OOTB variant again?
3. Rebuild or reapply all existing customizations on the new duplicate?

Or is there a better practice for keeping custom Workspace page customizations aligned with OOTB enhancements while minimizing rework during upgrades?

I'd appreciate any guidance on the recommended upgrade strategy and best practices for maintaining duplicated Workspace page variants.

Thanks in advance!

[martinvirag]

Hi!

Unfortunately, you have basically listed most of your options.
I usually review the new OOB variant, create a duplicate and then build my customizations on top of that. (but if the change is too small I just skip it) However, not necessarily in the UIB page designer itself, but on the macroponent or related list record.

Before AI, I compared them manually. Nowadays AI does the comparison between the two macroponent records and their related lists.

What helps is to document what you have changed or added as an extra feature. That way you can easily estimate how much effort the rework will be.

What I do as an approach though: reduce (minimize) what I add as a configuration to a page.

EG: for buttons I define it as a declarative action, if I add something custom I may add only a viewport and add a collection. So keep the original page as close as OOB as possible.

[Yamini_Kethe_24]

Actually, many customizations were done by existing developer and now we had an OOTB Feature issue
To fix that need to duplicate current OOTB Page and on top of those existing customizations to be rebulid.so,redeveloping all is time consuming and risky. Want to check how easy this can be done.

whether there are any alternative approaches that minimize redevelopment effort and risk.

[martinvirag]

Okay, but what are these customizations?

Do they affect only the layout?
Do they affect client scripts? New state params?
Or does it also include new data sources?

Because it completely depends on the approach.

If it's layout, then you can just copy over the customized macroponent's layout. If it's a data source, I'd recommend manually adding the data sources first (due to the unique binding abilities).

An approach here would be to a) download the macroponent and the OOB record and run an XMLdiff, or better: use an AI agent to compare the differences. You need to then basically go through the macroponent, its client scripts, its declarative actions, the connected data sources, and so on.

We once had an environment where the SOW was so heavily customized (but not with variants, literally customized on the macroponent record) that we had to revamp everything back to OOB and rebuild only the necessary customizations. 

Hopefully, someone else can give you an approach I haven't thought of. I have more than 400 hours in UIB but I'm really happy that it seems LUX will take over in the forseeable future:)