Order of commit for update set batches

[Mark244]

Does anyone know officially how ServiceNow determines the order of applying updates in an update set batch.  For example, if an update is captured in multiple update sets, when those update sets are batched together, how does ServiceNow know which one to apply first - does it order it by:

1. The sys_updated_on field on the sys_update_xml record itself, or
2. The sys_mod_count field on the sys_update_xml record itself, or
3. The sys_updated_on field in the paylod on the sys_update_xml record itself, or
4. The sys_mod_count field in the payload on the sys_update_xml record itself, or
5. Some other value or logic

The reason I ask is that sometimes developers need to move their updates from one update set to another because they accidentally captured the required change in the wrong update set.  If they happen to move an older update to the correct update set, and ServiceNow utilizes ordering based on 1 or 2 above, it is possible that the older update could be applied last as it was updated last or the sys_mod_count is potentially higher.  It would seem ordering logic 3 or 4 would make the best sense, but wanted to see if anyone officially knew how the commit process worked and how it ordered the updates across a batch.

[Marcos Kassak]

Hi @Mark244,

I have made many tests around this for the years and my conclusion is that the sys_updated_on and sys_mod_count fields on sys_update_xml records are the key, and these fields on the sys_update_xml table records (which represent individual update set changes) do play a role in determining when the update was made and how many modifications have been made to that record. 

I do believe that the payload order has an influence here whenever ServiceNow needs to organize to commit, and that's why there is a property to auto preview, so they can search for dependencies and tell you before committing that you need to solve some of them if they catch it.

The property is glide.update_set.auto_preview make sure to check if it's true.

https://docs.servicenow.com/bundle/tokyo-application-development/page/build/system-update-sets/hier-...

[Mark244]

Thanks Marcos for the reply.  I've been trying to test this for a few years as well, but sure would like to confirm.  There are potential issues if ServiceNow used ordering based on 1 or 2 above (sys_updated_on or sys_mod_count on the sys_update_xml record) as the mod count could vary dramatically and my not be a reflection of the latest version across all update sets in the batch, and sys_updated_on could also be off if someone moved the update to a different update set.  I may have to try test this scenario.

As for the glide.update_set.auto_preview, I usually disable that as I believe what it does is automatically trigger a preview of the update set  as soon as it is retrieved, which: 1) I don't like to do until I know all update sets and batches have been loaded, and 2) a preview should always be done just before you commit it as something could have changed in other update sets that this update set relies on.  But I welcome your thoughts and experience.

[AJ2025]

From Yokohama - When you preview or commit the base update set, you preview or commit the entire batch. The system determines the processing order, and checks for collisions, based on the dates the changes were recorded, and on their sequential ancestry. Their ancestries are the specific instances in which the changes in the update sets took place.

[carleen]

Awesome question! I've always gone under the assumption that the sys_updated_on from the sys_update_xml, was used in determining processing order. Generally, the payload and the sys_updated_on should match, so it doesn't matter exactly which one is used. That said, every so often, you have to edit the sys_update_xml record directly. Depending on how you do that, you may also update sys_updated_on in the sys_update_xml record, and that is when it becomes important to know the order of operations as you've asked. There may be other cases as well.

I encountered one of these exceptions today due to: KB0998255 - Everything in the [Document Template] scope is captured in the Update Set as 'Global' Their workaround for the problem is to run a script to move the sys_update_xml record to the Document Templates scope from Global. The script doesn't have an explicit order by, so it could apply this fix in an order that doesn't align with the order in which the updates were made, while also shifting all of these specific updates to the end of processing. Disclaimer: This script also has gr.addActiveQuery(); and sys_update_xml doesn't have an active flag, so I don't feel like I can infer any intention or answer from the recommended solution.

@Mark244 I'm curious to know if you ever got a definitive answer to this? 🤞