How are we supposed to work with configuration in Service Operation Workspace?

[Filip Vallberg]

Hi community,

How are we supposed to approach development and configurations within Service Operations Workspace (SOW)?

Currently, we're losing changes we've made to SOW pages. Since we're not allowed to modify the original page records, any updates from ServiceNow aren't applied to our custom pages. This forces us to manually reapply our customizations to a new clone or variant of that page. From an operational perspective, this is really problematic, especially as SOW undergoes more frequent changes.

Let me give you an example:

On the "SRP Record" page, I needed to change the "compose email" setting from "always" to "never." To make this small adjustment, I had to clone the entire page, creating "SRP Record_v1," and then implement my change. That part worked fine.

The core issue is that my cloned page won't receive any ServiceNow updates. So, to incorporate those updates, I have to create a new version of the page, based on the latest ServiceNow release.

This means creating "SRP Record_v2" (which combines the latest ServiceNow SRP page version with my customization).

This process is highly inefficient; we're essentially re-doing our changes every time we want to catch up with ServiceNow's new features and bug fixes.

This is just one example; we've made several other modifications in SOW and are encountering the same problem.

Furthermore, ServiceNow also suggests using page variants with audience and sort order, but this seems to lead to the same "rabbit hole." Our end users still won't see all our changes alongside new features from ServiceNow since they are not combined.

It feels like I'm missing something, as I sincerely hope this isn't how ServiceNow intended SOW (via UI Builder) to work.

It seems like they're telling us not to configure SOW pages at all, which is unacceptable from a customer standpoint. We need to be able to manage our configurations and receive ServiceNow features and fixes without this constant hassle.

Br

Filip

[Ankur Bawiskar]

@Filip Vallberg 

that's how it's done.

ServiceNow doesn't allow editing the OOTB page and you need to create a variant and then make changes to it.

Something similar behavior is there for OOTB widgets in portal.

yes during upgrades you won't get the enhancements as it's a custom page variant.

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Filip Vallberg]

Okay, but a widget is just a small component. Copying and creating a new one doesn't have the same significant impact as copying an entire SOW page, especially regarding new features and bug fixes that affect the overall SOW experience.

My question then becomes: How are we supposed to manage this process over time as more and more changes are applied?

Since we want to incorporate new features, we need to merge our customizations with a newer version from ServiceNow. How can this be managed in a smooth and controlled way?

We can't rely on update sets because they will point to the srp_page_v1 version, not the new one we'd want the changes applied to.

So, is the only solution to document every configuration step and re-apply them all in the new version? This feels incredibly inefficient and problematic. It might be manageable for a single change, but with multiple configurations and significant customization, it becomes a tedious and mundane task to get everything back.

[Ankur Bawiskar]

@Filip Vallberg 

you can check the skipped logs when upgrade happens.

I believe it's somewhat difficult to track the UI builder components but if you know in skipped log then you can copy the OOTB one and then again add your customizations on top of it.

If my response helped please mark it correct and close the thread so that it benefits future readers.