Why is AUDIT not enabled on TASK table?

[pauluksteam]

We are having trouble identifying rows deleted from the TASK table because they don't appear to be logged on sys_audit_delete table. This means SnowMirror isn't able to identify rows to be deleted from the on-site copy using the default (most efficient) method and results in row-count mismatches. It surprised me that AUDIT is not enabled for TASK. This appears to be the case in all our instances and in the default off-the-shelf instance available on the Dev portal. Can you please explain why auditting is not enabled by default, the implications and cost (overheads) involved if we switched this on?

[Pradeep Sharma]

Hi Paul,

By default, the system does not audit records from system tables.

Auditing certain system tables that receive a large amount of traffic,can impact performance and is not recommended

Turning on Auditing (History) for a Table - ServiceNow Wiki

[Brad Tilton]

Hi Paul,

I think it's turned off to allow customers to have more control over the instance. If you take a look you'll see that all tables extending task DO have auditing turned on so it's not really an issue. In this case you could extend task and choose whether or not to audit the extended table.

[pauluksteam · Accepted solution]

I have also had a response from SnowMirror support separately from this thread.

"The task table is not being used as a standalone table in the ServiceNow platform at all. It is always an incident, problem or any other entity derived from task.
All of these task entities are audited by default. So if there is a delete in one of the child tables then the sys_audit_delete table contains a reference to this child-table record (and not to the parent task record). However, the delete strategy algorithm is smart enough to deal with it. It queries the delete log for all child tables too. So the audit delete strategy works for the task table even it itself isn't audited."

Regards,

Paul