Share pages across Experiences

[Martin Rudack]

In ServiceNow, Workspaces are modern UIs built for specific personas or roles. They focus on the core tasks these users need to complete.

Today, there are more than 50 out-of-the-box Workspaces shipped by ServiceNow. With so many available, it’s not surprising that there is an overlap in tasks these Workspaces can perform, and maybe one Workspace might handle this specific task better than another.

When you face this situation, you usually have three options:

• Switch Workspaces for that task – Not ideal. It forces users to jump between UIs, which is the opposite of what Workspaces are meant to solve.
• Copy or recreate the page in another Workspace – Also not good. It leads to high maintenance and duplicate work.
• Stay in your current Workspace and live with the limitations – The worst option. It creates a poor user experience.

So, what’s the solution?

Let’s say you’re a CSM agent using the CSM Configurable Workspace to resolve cases. Sometimes you need to open related incidents and work on them as well. The CSM Workspace supports incidents, but the Service Operations Workspace (SOW) offers a much better experience for managing them.

With the Zurich release, you can now use pages across Experiences. There’s no need to copy or recreate pages. With a few simple configurations, you can display the SOW record page inside the CSM Workspace.

And as a bonus: with the Service Operations Workspace ITSM Applications 8.0 Plugin, some SOW pages are already marked as shareable. You just need to configure which Experience should use them.

 These are the steps you need to do:

1. Configure a page so it can be shared across Experiences.
2. Create a configuration to consume the shared page in another Experience.
3. Ensure that additional routes for the shared page also work in the target Workspace.

1. Share a page

To share a page, go to the UX App Route record [sys_ux_app_route] and enable the Use across experiences [interoperable] attribute.

Once enabled, you’ll see a small blue icon in UI Builder showing that the page can be used in other experiences.

Keep in mind: users still need the right access and audiences, also conditions still need to apply.

2. Consume a shared page

To use a shared page in another Experience, create a UX Cross-experience Route [sys_ux_interoperable_route].

For example, you can configure the SOW record page so it’s used in the CSM Workspace. If you configure it like on the screenshot above, you will notice that the SOW record page will be used in the CSM Workspace not only for Incidents.

Add a usage condition such as table=incident and the SOW page will open only when incidents are viewed.

This configuration is also visible in UI Builder. Make sure you’re on the latest UI Builder version, otherwise, you won’t see the new indicators.

3. Configure dependencies

Now, the SOW record page can be used for incidents inside the CSM Workspace. But there is one more thing to handle:

Shared pages may link to other pages that don’t exist in the target Workspace. To avoid broken navigation, you need to define the missing routes.

This is done with UX App Linked Routes [sys_ux_dependent_route]. These records link the missing route to the shared one so that it’s also accessible in the borrowing Workspace.

If you have updated the Service Operations Workspace ITSM Applications Plugin to version 8.0, these dependent routes are already included.

[matthias-b]

Hi Martin,
thank you very much for sharing this extremely helpful feature. The constant switching between CSM and SOW was a problem, especially in cases where external customers were being supported with IT issues.

The condition appears to be an encoded query. If multiple tables are to be included, this can be done with '^OR':
table=incident^ORtable=change_request

[boteeuwen]

Thanks for sharing this Martin, this feature looks really promising.

I have a quick follow-up question. If we configure the SOW record page to open inside the CSM workspace using the Share pages across Experiences feature, will all the UI actions and functionality that normally appear in SOW also be available in CSM?

For example, when opening an incident in the CSM workspace with the shared SOW page, do you see the same buttons and actions as in SOW like Resolve Incident, Link Case or Create Work Order?

Are there any differences in how UI actions or client scripts behave when the page is used in another workspace? And do any of the UI actions need to be reconfigured, for instance by setting the Workspace Form Button or Workspace Form Menu flags, to make them visible or functional in CSM?

Curious if you’ve tested this or noticed any limitations when sharing pages across experiences.

[Martin Rudack]

Yes it will load the SOW page and you get the UI Actions configured for that page and not the CSM page.

One thing that could happen is that one of the UI Actions of the SOW record page will use a route that is not configured for the CSM Workspace.

For these use cases you will need to configure the dependencies like described in the blog post.

That’s the only thing I noticed so far.

[ctsmith]

This was amazing!  This is currently the only place I can find how to do this.  Even the SN docs page sends me to an error.  Nice work @Martin Rudack !  I'm actually sharing the IT Remediation Workspace list across to the SOW. 

Now... as is, SOW also has a list page so it overtook that one.  One extra bonus is that I created a new page in SOW in UI Builder with it's own unique URL path.  I then added that url bath in the Alias route field on the UX Cross-experience route record.  Additionally, I created a new side navigation icon that references the custom SOW page (that the alias route uses) and so users can click between both icons to see the SOW list and IT Remediation workspace list.

This definitely lends towards the single workspace as a single pane of glass across products with less clicks.

[Sabrina Devett]

Hi Martin, 

Thanks for this - very useful! Do you by any chance know if it can work with pages with "extension point" ?

My usecase is that I want to share the "Communicate" tab from incident/SOW to CSM/FSM workspace and for cases. As far as I see, I can't do this by following you guide, since the "Communicate" sys_ux_app_route is extended from "SOW - Records tabs middle".

When creating the sys_ux_interoperable_route - the source_route field has a condition saying " extension_point = empty" OOTB. 

Any good tips? 

BR,

Sabrina

[Philemon Anton1]

Hi Martin

Thanks for your instructions, they worked great. I have multiple custom workspaces and I use the interoperability feature to share certain pages (e.g. "Email Composer" or "Record Producer" record variants). This allows me to define certain pages in a "base" workspace and reuse it across all my other workspaces. That seemed to work fine so far.

Now I realized all my workspaces use some outdated list page and my idea was, I add the newest version of the list page template to my "base" workspace and then use the same list page across all my workspaces with the interoperability feature.

Now I run into the following problem: The list page gets the list configuration from the app context (@context.app.listConfigId):



This means in my case, it would never show the list configuration of the workspace I am actually in, but always the list config of the workspace the "reused" list page was configured in. In my opionion this does not make sense and there should probably be some way to at least define if the shared page uses the app context of the source experience (where the page was defined) or the target experiene (where the page was reused with interoperability).

Did anyone run into the same issue or has a solution?