What is the skip_sync field on Asset or CI record, and how it can break Asset-CI synchronizationIssue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } It is used to tell the Asset-CI Synchronisation code to not sync from the CI to the Asset, or Asset to the CI, as part of the record update() that is about to happen. The skip_sync flag is used to prevent recursion within the same cycle of business rules and will be reset in the next cycle during Asset-CI synchronization. The skip_sync field on Asset and CMDB CI records is more of a flag than a field, but is still an actual field/column. It can be set as if it were a field, in the normal way, on Asset and CMDB CI GlideRecords in code, but usually exists only in memory, in the GlideRecord object of the record, as business rules run during the current transaction/update. The skip_sync flag is set to false by default. A record at rest in the database should have this set as false. If set to true on a record, the Asset-CI Sync business rules will not run on the next update for that record. But if you do see the actual field set as True in a record, then something must have gone wrong. There are OOB script includes and business rules that will be involved in any CI or Asset update: AssetAndCISynchronizer: /sys_script_include.do?sys_id=9ec37b411b012000e49bfbcd2c071380Update Asset fields on change: /sys_script.do?sys_id=31e93aaf1b3210002502fbcd2c0713d8Update CI fields on change /sys_script.do?sys_id=4d15855c1b0310002502fbcd2c071399 Without the skip_sync flag, the two business rules above would be triggered twice during an Asset-CI synchronization, and would actually loop out of control if it were not for the platform's Recursion prevention code. The skip_sync flag should have been set to false again after the synchronization. In case the skip_sync flag was set to true for some reason, an update on the Asset/CI should help set the flag back to false. It can also be used in: Business rules. 'Update Asset fields on change'/'Update CI fields on change' are the main and original user of this. e.g. a CI update will want the BR to update the linked asset, but doesn't want BRs running for that Asset update to update the CI back again.A business rule running at an order before those out-of-box ones can set it, and prevent them running.In GlideRecords in scripts, prior to making a .update(). You may want to do an update to a record from e.g. a scheduled script, but can't use .setWorkflow(false) because you do still need business rules/engines to run, but do not want the 'Update Asset fields on change'/'Update CI fields on change' business rule to run.In IRE input payloads.There are several examples in the docs of "skip_sync": "0", being used in the payload JSON. This would guarantee the insert/update starts with the default skip_sync=false. Symptoms<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } skip_sync changes to 'true' and stays that way in the record even after the transaction has ended. That breaks Asset-CI sync on the next record update. It doesn't change back to the expected false value until another update is made to the record. Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Any Cause<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Usually it is seen that a custom business rule, using the current.update() command, before or after insert/update/delete. That's not just bad practice, but is forbidden in the platform. You cannot cause an update within an update that's already happening. If that is done, then all bets are off. Multiple GlideRecord objects for the same record will exist in memory, with different field values, at the same time. Which object 'wins', and ends up in the record at the end of the transaction, is not something that can be known in that situation, and will usually appear random. Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } The general rule for business rules making updates are: If it is to change a field of the same record being updated, then it is done in a 'before' business rule, where no additional update() is required because you are already part of one. The update to the database record hasn't happened yet at this time, so you can piggy back updates to other fields of the same record into the update that's already happening.If it is to change a different record in the same table or another table, then it is done in an 'after' business rule, using .update() for that other unrelated gliderecord. Asset and CI records have an additional restriction, which is that the out-of-box business rule mentioned above are already making updates to the 'other' record - CI updates Asset/Asset updates CI - and so any additional business rules making updates to those linked records in the same transaction, before or after, are likely to cause recursion anyway. Doing that and using current.update() in an attempt to try to workaround that fact is always going to break something. Business rules that trigger on CI/Asset operations that end up updating the related Asset/CI record, either directly, or via additional tables/records' business rules, need to be avoided. If necessary, using an Async businss rule, so that the update happens in a separate transaction, is the best way.