Missing audit \ activities

[Wayne Richmond]

One of my first line teams has notified me of an issue where activities in a ticket have disappeared, namely the Work note and the initial activities. Here is what a good ticket looks like:

But here is what a ticket looks like where the information has disappeared:

You can see the first activity recorded is an email that was sent, rather than when the ticket was opened and all the other activity information. There should also be a Work note here as well. 

Reviewing the audit history doesn't show any additional information.

Has anyone come across this before?

[Prasad Pagar]

Hi, 

Please check if user you are checking with have access to read worknotes and required activities? May be some ACL blocking

Thank you
Prasad

[Wayne Richmond]

Thanks Prasad, but I don't think that's the issue as I took these screenshots as an admin

[Wayne Richmond · Accepted solution]

ServiceNow provided the solution:

The cause I believe is due to sys_audit record's being generated as a result of a business rule on the sys_email table:
Business Rule: [Update 4747 Email field](https://******.service-now.com/nav_to.do?uri=sys_script.do?sys_id=7bcae9d11bce4d10942bfc4cd34bcbc9)

This business rule results in sys_audit being created for the call log which has a record checkpoint = 0.

Why does this matter?
- The Activity Stream is built from History Set(s) which act as a sort of time-limited cache, and hold information gathered principally from sys_audit, sys_email and sys_audit_relation which is tailored to the end-user's language, date/time format, domain and timezone.

- Out-of-the-box instances don't audit inserts, with the principle reasons being the impact it can have in terms of the overall size of the sys_audit table (typically 80% larger) and then the impact that can have on clones and upgrades.

- Audited inserts have a record_checkpoint=0.

- The record_checkpoint values are taken from the audited record's sys_mod_count

- The code that builds the History Set reads all the sys_audit for the record and if no audit is found with record_checkpoint=0 it then extrapolates the initial values for the record from the non-null oldest oldvalue from sys_audit, and if there is no audit then the current value in a field is assumed to be the initial value. This includes querying sys_journal_field to find any comments/work notes created when the record was first inserted.

- If the History Set loader code sees any audit with record_checkpoint=0 then it will assume that inserts were audited and therefore that the initial values will be found in the sys_audit, and therefore it does not extrapolate the initial values.

Here is where I think the problem lies

var gr = new GlideRecord("x_mibu_4747_call_log");
...
        gr.autoSysFields(false); // don't update system fields
        gr.sys_updated_on = current.sys_created_on;
        gr.sys_updated_by = current.sys_created_by;
        gr.update();

autoSysFields(false) can cause 'odd' issues if you don't understand the potential impact this can have on auditing. This API call prevents GlideRecord from setting the system fields and can be legitimately used as you are doing to override the sys_updated_on and sys_updated_by, as clearly you want to use the information from the email on the call log.

However, it also suppresses the increment of the sys_mod_count field. If the sys_mod_count on the call log record is currently 0 and the email is sent generating its own sys_audit, that would appear to use the sys_mod_count of the call log record, leading to sys_audit record for the email with record_checkpoint=0.