Recently I faced a scenario where a record had been accidentally deleted on a production instance. Unfortunately, the record had also been removed from all the available sub-production instances as well. Luckily, on production instance, the record was still stored in the deleted records module (also known as sys_audit table) this meant that the file was easily recoverable.
As you may already know, Service Now tracks all changes performed on its base tables in the sys_audit table. And you can restore by following the process below.
However, on the sub-production instances being worked on, the sys_audit table had been cleared prohibiting me from utilising the above process.
Without going into too much detail, there were a variety of constraints preventing me from restoring the record to the sub-production instances in a tradition manner that would satisfy best practice principals.
Before getting into how I got around this issue, I should mention that for a file to be parsed by the Service Now table XML import utility, it must first adhere to stringent formatting.
In the video below, I will demonstrate a method manipulating an XML file in such a manner that it can be parsed a table XML import utility and potentially sent to an alternate instance for uploading.
The next time you export a record as an XML file, pay close attention to the first 3 nodes of the XML document. In the example below the unload_date parameter should be filed with the date time you wish to set for the record, and the tableName node should be replaced with the name of the table the file is to update. For example, the sys_user table.
As you will see from the video below, I am able to parse the XML document through the table importer application once it has been formatted correctly. This, of course, presents an end user with the opportunity to utilise the import function for relief if the occasion should present itself.
Let's keep this our little secret...
1 Comment
