How can I capture updates from different scoped applications in common update set?

[arpitt]

Hi Folks,

I was wondering how can we make changes in security incident table and threat intelligence table and capture the same in a common update set?

Thanks

[andy_ojha · Accepted solution]

Hey there,

You actually will run into issues if you perform this, when trying to apply and commit your update sets.

Your update sets should only contain updates, for the respective application scope they were created in.

You should create update sets to track your work in respective application scopes.

To make it easier to migrate and work this a large volume of update sets, you should investigate using the 'batch update set' functionality:

https://docs.servicenow.com/bundle/london-application-development/page/build/system-update-sets/hier-update-sets/concept/us-hier-overview.html

If you create your parent update set in the Global scope, you can have child update sets in various scopes.  Then you can simply migrate your parent update set.  The processing / ordering will performed at the batch level and you do not have to worry about applying update sets in a certain order.

[francescodotti]

In order to add an important detail of the procedure, you cannot add a Child Update Set to a Parent in different application scope starting from the form of the Parent Update Set. But you can add the field "Parent" in the form of the Child Update set and specify the Parent from the record of the Child Update Set, even if  it is in a different Application Scope.

[Mohammed Kemal]

Hi,

You can do this by adding update_synch in dictionary override. If you want to specifically migrate data, you might use an instance-to-instance import.

In ServiceNow there is a default rule blocks the use of the update_synch attribute on a table for which it is not predefined to bypass problems.

To see the list of tables where customizations are tracked, navigate to System Definition > Dictionary and filter on attributes CONTAINS update_synch.

Attributes is not there by default so you will need to move it from available to selected as shown below: 

then 

As you can see above ServiceNow set the above tables rule blocks for update_synch. 

It determines which records get captured in update sets. Without it, you could miss key configurations to your system.

 here is the issue you might be facing in::::::> and this is because it might be a cause of the following issues:

• Some core tables require special update handling because they represent information on multiple tables. When the update_synch attribute is added to these tables,
• • duplicate update records are created => causing major conflicts that are difficult to troubleshoot and repair.
• Using the update_synch attribute to migrate data records between instances can
• • Cause performance issues => because it is not intended for this purpose.

I hope this might answer your question and let me know if you have any other questions or comment.

Best Regards,

mokemal!!!