When I try to create a Clone Preserver on the table Update Sets (sys_update_set) the User Interface

[William David]

When I try to create a new Clone Preserver, as part of an existing Clone Profile, for the table "Update Sets" (sys_update_set), my entries in the Name and Table field get immediately erased when I move my cursor from the entry boxes. It is as if there is a rule preventing me from creating a Clone Preserver. Additionally, I CAN find and select the Update Sets table (sys_update_set) in the "Table" entry field, but as described above, that selection is immediately counteracted by this mysterious rule.

I am aware that there is a Clone Preserver Setting "No. of days of In-progress Global Update Sets to be preserved". Was the logic implemented behind this setting something that was implemented in place of allowing Users to create Clone Preservers on the Update Sets table (sys_update_set)? Additionally, how are the days selected by this setting related to the various Update Sets? Are the "number of days" calculated from the Update Set creation date, of from the Update Set modification date, or some other date associated with the Update Sets? If we cannot create our own custom Clone Preserver on the Update Sets table, then we'll need to understand this setting clearly, with regards to the phrase "no. of days", so that we can use it confidently in the place of a Clone Preserver.

[Paige Duffey]

Hello!

I am sure that the system prevents you from doing this because it would be problematic. Even if you could preserve the table it would only preserve the Update Set "Container" and not the actual changes in the update set.

The "In-Progress Update Set" preservation does not preserve update sets in the sys_update_set table. It instead brings them into the Retrieved Update Sets table so that you can reapply them.

Update Sets need to be reapplied into the fresh clone. They cannot just be "preserved" as their changes impact tables all over the platform.

[William David]

I understand that this behavior was likely designed by Service Now. I also understand the two-tier nature of Update Sets (that they are a container for Customer Updates - the raw XML instructions for modifying the platform).

What is needed is an explanation of the Clone Preserver Setting "No. of days of In-progress Global Update Sets to be preserved". If we're going to use this built-in capability, then we need to know when the "No. of days..." is calculated from. Created date? Updated date? Some other date?

[Paige Duffey]

It appears, according to the docs, that it preserves global update sets created within the last 90 days.

https://www.servicenow.com/docs/bundle/xanadu-platform-administration/page/administer/managing-data/...

I would recommend, though, if this is your first time using the to export the update sets manually until you are comfortable with that functionality.

[William David]

Paige,

It is technically not "created in the last 90 days", because the loading of a Retrieved Update Set can artificially refresh the "Created" Date/Time field. Your Update Set could've been created 2 years above, BUT if you preserved the Update Set by exporting it, retrieving it, then re-committing it, it will APPEAR to have been created more recently.

We still need to know how to automatically preserve Update Sets that are NOT in the Global Application Scope.