Is there a table on Service Now that logs changes to field values etc?

[SB87]

Say I have an incident, "INC123456" and I want to report on when the 'status' of this incident changed, or the 'assigned group' changed, or to get a timeline of 'reopened_time' entries.

Is there a table on Service Now that logs these sort of changes that I can use?

Many thanks,
S

[Soeren Maucher · Accepted solution]

Hello @SB87 , 

yes there is the audit function in ServiceNow, which will log exactly those changes. If there were no changes to the out of the box configuration on your instance, this feature should be enabled on the incident table. You can access the audit logs as shown in the following screenshot: 

Keep in mind, this feature is not enabled for all tables since it will generate a lot of log records. If there is another table you want to audit that is not audited out of the box, you can enable the feature for further tables. See the following article: https://servicenowscholar.com/2019/07/31/enable-auditing/#:~:text=First%20navigate%20to%20the%20dict....

I hope this helped. If yes, I would appreciate if you could mark this answer as "correct solution". Thank you!

[Dubz]

The sys_audit table logs these changes for any table for which you have enabled auditing. It's enabled by default for a lot of the main tables like incident, problem, change etc. 

Reporting on system tables isn't possible by default and isn't best practice as they tend to be pretty big so your reports are going to take a long time and consume resources. Your best bet is to create metrics (or see if any of the OOTB ones fit your requirements) to track changes to the fields you're interested in and then report on the metrics.

If you really need to report on system tables you'll need to add them in to the glide.ui.permitted_tables system property but proceed with caution.

[Soeren Maucher]

Hello @Dubz, 

I agree with your points. I missed the aspect of "reporting on". If @SB87 wants to build a report/dashboard on this, then a metric would definitely be the better choice. 

If it is just to find out manually who edited this record (e.g. who has altered the ticket and set the wrong assignment group) then that would be a classical use case of the audit table. 

As always it depends on the requirements. 

Greetings,
Sören