Behavior when an Update Set contains changes from different scopes

[多和田汐]

I am currently learning more about errors that can occur when migrating Update Sets in ServiceNow, and I would like to understand what happens when changes from different scopes are included in a single Update Set.

To verify the behavior myself, I prepared two ServiceNow instances and tried to migrate the Update Set between them. However, I was unable to complete the connection test successfully, so I decided to ask the community.

Scenario

I am assuming the following situation:

・Update Set scope: Global

・Changes included in the Update Set:

       -Changes in the Global scope

       -Changes in a Scoped Application

If I migrate this Update Set to another instance and perform the following steps:

Retrieve

Preview

Commit

what would happen?

My current understanding is that a Preview Problem would occur during the Preview step because of the scope mismatch, with an error similar to:

Update scope id 'xxxx' is different than update set scope id 'global'.

I assume that the Update Set cannot be committed until this issue is resolved.

Also, in this case, is it correct to understand that the Global changes and Scoped Application changes should be placed in separate Update Sets and migrated individually?

If my understanding is incorrect, or if there are any additional considerations regarding this scenario, I would appreciate your advice.

Thank you in advance.

[pururavasin]

Hello,
While working on an element which is on a different scope than your current scope,
system prompts the following message:

Its a safe practice to create a separate update set of each scope, and then capture the modifications.
However, if we still manage to capture the changes of a different scope in the update set, 
we may encounter warnings while Previewing/Committing the update set.

For e.g. 

If the Scoped Application does not exist on the target instance, additional problems may occur during Preview or Commit.

If the need is to use an object which lies in a different scope, the Cross Scope Access Privilege can be defined & captured in the current update set.

Best regards,
Puru.

#Note: Please mark this response as helpful/correct.

[Hemanth M]

Hi @多和田汐 , 

You are correct. These are the scenarios:

1. Sometimes, updates from a different application scope are captured within a single application scope (mainly in Global) - this will throw an error as you mentioned

2. Most of the time, if you try to capture an update outside of your current application scope, it gets captured in the default update set of that outside application scope.

Example:

Application Scope A: Your current application scope.

Application Scope B: The component you are trying to capture.(outside application scope)

Result: It will be captured in the default update set of Application B.

What is the best approach?

1. Capture these updates in their respective application scopes.

2. Create a new update set (preferably in the Global scope).

3. Create a batch: Add all the different application update sets as children to the update set created in step 2 (use the parent field of the child update sets to tag them).

4. Complete and move this single parent (batch) update set across instances.

Hope this helps!

[Hemanth M]

Hi @多和田汐 ,

If this response helped, please close the loop by accepting the solution. If not, please ask a follow up question