How to handle cross-scope issues when deploying Employee Experience Taxonomy scoped app for ESC

[David Trotta]

We are deploying Employee Service Center in our environment. When building the Taxonomy (mega menu) structure in lower environments, I was continually prompted to move to the Employee experience taxonomy application scope (the OOB application scope) as I built out the topic structure (topics, child topics, etc.) and moved the catalog items under the proper topic. However, many of the catalog items were built in a different scope, such as the "global" scope or a custom application scope.

Now, when trying to promote the Employee experience taxonomy application scope, I am getting many cross-scope preview problems (like the one below) and my only option is to "Skip Remote Update."

Has anyone else encountered this? If yes, how did you handle? What is best practice when initially building your taxonomy for ESC and trying to capture the taxonomy topic changes for catalog items? It seems very cumbersome to make the changes in each individual application scope, especially when making dozens of taxonomy changes.

Example of cross scope preview problem:

"Cannot commit Update Set 'EC_Taxonomy_20241210_DT_Phase2' because: Update scope id '7f5dabf71b7df1908decc9da234bcb08' is different than update set scope id '9f678ed6c3003010069aec4b7d40ddba'. Resolve the problem before committing."

I appreciate any guidance on how best to handle this situation.

[Sebastian L]

It is because the update you have created is in another scope than the updateset you have licnked them in. You need to add those customer updates to the right updateset. So find the customer update, and move that specific update to an update set with the corresponding scope.  

So let's say your updateset is global, but your update is done in Employee Experience Taxonomy, then it is captured in the wrong update set. It usually happens if you click the "change in scope now" (can't remember the exact wording). You need to make sure to switch to the right application scope before making any updates. 

And just to your point about chaning for each update - that is not needed, you simply need to be in the right updateset of the right scope when you do the changes.

[David Trotta]

Thank you, Sebastian, for the quick response.

When updating the Taxonomy, I would often get the message "You are in the XXXX scope, but you need to be in the Employee Experience Taxonomy scope (also not sure of exact wording), so I would often follow the prompt and select the proper Application scope as directed and the message would go away.

A follow up question.

When building my ESC taxonomy, I associated my taxonomy topics to multiple existing catalogs, which in turn added a couple hundred catalog items to the taxonomy topic with a few clicks of my mouse.  To instead, have to go into each catalog item individually seems like a lot of overhead.  Plus, does that mean I should never use the Employee experience taxonomy application scope?  That is an OOB scope app and appears to be one of the OOB apps associated with ESC (along with Employee Center and Employee Center core apps).

I was hoping there was another solution versus touching each custom application scope.  Plus, I don't want to pull in other changes being made to the catalog item by other developers on the team (like modifying the form and workflow, etc.), especially since my change is only to the taxonomy topic field on the catalog item.

Thanks again for your response.

[Community Alums]

(Sorry responded from my partner profile) 

What you have done is fine and correct when adding the items to the topics, so no worries there.

It is simply a matter of you being in the right scope and updateset when you do the action. When you click the prompt you specified there, you will be allowed to add it in the "right" scope, but it will appear in the wrong updateset - it is such a bad UX from ServiceNow that they even allow this. So instead of clicking that "here" link, you need to select the right scope from the UI (top right) and THEN do the action your want to perform. 

Then you simply batch the two updatesets together so they can be deployed together and without any issues with "order of creation" etc. 

[David Trotta]

Thanks again for the response.

When you say "It is simply a matter of you being in the right scope and update set when you do the action."  When I used the action of adding a catalog to a taxonomy topic (for example "submit a request" catalog), it involved pulling over 100 catalog items under the taxonomy topic, many from different scoped apps.  So how do I pick the right scope when it touches multiple scoped apps.

Am I overthinking something?