Is it good practice to use sys_audit table to pull and show history data on form for custom table entries?

Mihir YSSS
Tera Contributor

I need to display data from custom table while doing the approval with history of changes. Initially data will coming from SQL and will store in custom table. People will modify data then submit. Approver should know which fields were modified from which value to which value. Since all the modifications will be stored in sys_audit table, I want to retrieve related records from this table. Now the question is,

  1. since sys_audit table will record every change in system, which leads to grow enormous in number, is it good practice to read from this table to showcase differences?
  2. Will there be any need to wipe out data from this table at any point in time in production in future?
  3. Impact on the reports if we need anything for historical changes

I found one article here, is it suggestable to follow?

 

 

1 ACCEPTED SOLUTION

Tony Chatfield1
Kilo Patron

Hi, it is not best practice to query sys_audit and sys_history data as part of a BAU process and regularly running queries against these tables has to potential to impact your platforms performance.

The article you linked from ServiceNow clearly indicates that there are risks, and it is not recommended as a suitable solution.

Without very clear details of your business requirement\needs\expectations and the underlying justification it's difficult to suggest suitable alternatives.
Perhaps you could add a field to your custom table that identifies the original record and then insert a new (version) record referencing the original (or the previous 'current' record) every time there is an update.
This way you could use a single table script to compare versions of the record.

 

 

View solution in original post

3 REPLIES 3

Tony Chatfield1
Kilo Patron

Hi, it is not best practice to query sys_audit and sys_history data as part of a BAU process and regularly running queries against these tables has to potential to impact your platforms performance.

The article you linked from ServiceNow clearly indicates that there are risks, and it is not recommended as a suitable solution.

Without very clear details of your business requirement\needs\expectations and the underlying justification it's difficult to suggest suitable alternatives.
Perhaps you could add a field to your custom table that identifies the original record and then insert a new (version) record referencing the original (or the previous 'current' record) every time there is an update.
This way you could use a single table script to compare versions of the record.

 

 

@Tony Chatfield  Will there be any chance that audit table data get wiped out automatically for any reasons, Eg. data storage become huge?

It is possible to truncate/prune audit data to recover/save space, but I am not aware of it happening automatically.
- if concerned you should seek clarification via SNC support and/or your SNC account manager.

Whether you would ever need to consider truncating audit data depends a lot on your instance size, configuration and usage; I would suspect for the majority of platform customers it is never a consideration.