How to Report Incident Field‑Level Changes When Audit/History Tables Are Restricted?

[SHUBHAM78]

Hi Community,

I need guidance on a reporting requirement related to tracking how Incident fields changed over time.

A business user wants to analyse historical changes for Priority 1–3 Incidents across specific queues. The required change details include:

• Priority changes
• State transitions
• Assignment Group changes
• Who made the update and when

However, in our ServiceNow instance:

• sys_audit access is restricted and cannot be shared with end users
• sys_history_line is not available as a report table
• sys_journal_field is also not available for reporting
• These tables cannot be added to a Database View because they are system‑restricted

This means we cannot capture field‑level change history using standard reporting or DB Views.

My Questions for the Community:

1. Is there any OOTB method or reportable table that provides field‑level change tracking without using sys_audit, sys_history_line, or sys_journal_field?
2. Is there a configuration or ACL setting that can safely expose these tables for reporting?
3. What are the recommended best practices when detailed field‑change history is needed but audit tables are restricted?
4. Are there alternative approaches other customers use for workflow‑change analysis in similar restricted setups?

Currently, the only available option seems to be reviewing the Activity Stream manually on each Incident, but this is not scalable for large datasets.

Any suggestions, alternatives, or best practices would be greatly appreciated.

Thanks in advance!

[Ankur Bawiskar]

@SHUBHAM78 

why not use incident_metric database view which stores these details via metrics?

It stores state change, group change.

You can create metrics for Priority and use in that database view

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Ankur Bawiskar]

@SHUBHAM78 

you can allow system tables in reporting by adding them in this property "glide.ui.permitted_tables"

But I won't recommend reporting on this as tables are huge and will impact performance.

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Ankur Bawiskar]

@SHUBHAM78 

Thank you for marking my response as helpful.

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[miftikhar20]

Hello @SHUBHAM78,

The OOTB Solution: Metric Definitions 
You don’t need the audit table! The standard OOTB method is Metric Definitions. You can define a metric for specific fields (like State or Assignment Group). This writes to the metric_instance table, which captures the value, start/end time, and duration. You can then report on this easily using Database Views (e.g., incident_metric). 

Can you expose Audit Tables?  
Technically, yes. You can add sys_audit to the glide.ui.permitted_tables system property and add an ACL. However, this is highly discouraged. sys_audit is usually the largest table in the instance. Reporting on it can cause massive performance degradation.
Also, avoid sys_history_line for reporting, it is transient and flushes older records after 28 days of inactivity, so your reports will be incomplete. 

If my response helped, please mark it as the accepted solution so others can benefit as well.