Cannot commit Update Set :Update scope id is different than update set scope id 'global'

[Artemis15]

Hi

I'm getting below error.

We take backup from our dev instance and cloned it from Prod. Our dev instance was just upgraded to Fuji and we are creating a new application (not via application module).

We have taken backup using update set but after cloning, when we are trying to load update set than we are getting following error.

Cannot commit Update Set because: Update scope id '811e4bc56f8f31005de9f00dba3ee4fc' is different than update set scope id 'global'. Resolve the problem before committing.

Please help me on this.

--

Cheers,

AR

[Greg10]

Similar happened to me when a global update set managed to pick up some cross scope access entries happening in an application scope.  In my case, I was able to delete the changes I didn't want out of the update set, and then re-export, and retrieve again.  ( I didn't want this happening when going to Prod, and it was showing up when going to UAT.)

So that's my advise, decide if you actually don't want these items in your update set.  And if so, then you could just skip them.

[Armacar2]

Hi,

For those who are new to ServiceNow and are having this issue, the best way I found to fix this, is by going to the sys_update_xml table, group by the update set column, then find yours and expand it, in the column "application" change each update row to the scoped application you want to have them (just make sure all belongs to the same scoped application) and save the changes, then procced to retrieve your update set again in the destination instance (you gonna have to delete your previous "previewed" update set in the destination instance before retrieving it again).

I hope this helps.

Please mark as helpful or solution if this works for you.

[Inactive_Use270]

Thank you very much for posting it here. This helped me and saved my time.

[Inactive_Use270]

Thank you very much for posting it here. This helped me and saved my time.

[G24]

In my case what this error meant was that a change (a Customer Update) somehow got into an Update Set with a different "Application" value.

The solution for me was to change my current application to Global, then create a new Update Set (in application Global), and move my Customer Update (my change) into that new Update Set.