Loading the audit history list or calendar of a particular record takes a very long time to load where it times out my transaction - Support and Troubleshooting

Loading the audit history list or calendar of a particular record takes a very long time to load where it times out my transaction Issue - When I get on a form, then click the 'List Controls' (on the upper left) ---> then click History -----> Calendar OR List, it takes a very long time to load where it also times out. - This only happens on certain records and not all records Cause 1) This is related to PRB645035 where there is no permanent fix because it is expected behavior for the history set to take a very long time when there is a lot of audit history for a particular record

2) Every time you click the history List, it executes the below UI action to create the history set, if there is no existing history set, or if the history set is expired after a month, or if there were updates made to the particular record:

UI Action - Show History https:// [Instance-Name] .service-now.com/sys_ui_action.do?sys_id=7eda37860a0001c700824a6f277327b0

Object Type: UI Action [sys_ui_action] Sys ID: 7eda37860a0001c700824a6f277327b0 Field Name: script Line Number: 2 Function Name: script

1: var hs = new GlideHistorySet(current); 2: >>> var sys_id = hs.generate(); 3: 4: action.setRedirectURL("sys_history_set.do?sys_id=" + sys_id); 5: action.setReturnURL(current); Resolution There are a couple of solutions that can be done: Solution One (Recommended): Delete old audit data and minimize the audit record list to lower than 1,000 for the particular record that takes a long time to load the sys_history_set Solution Two: a) Go to https:// [Instance-Name] .service-now.com/sys.scripts.do b) Run the below script to manually build the history set for the particular record that has too many audit records: NOTES: i.) Make sure the below sys_id is the sys_id of the record your getting the history set on ii.) Since the script below will take a long time, open a new browser in incognito mode/ private mode and re-login to Servicenow to do other stuff as your long script is running so your not impacted by session_wait_time

What is session_wait_time? This occurs when a user executes too many transactions at a time in parallel. A user can only access one transactions at a time as designed. This issue occurs a lot when a user has too many Servicenow tabs open and works too fast. For Example: If you access or save anything on a form, then while thats running you immediately try to access or save another form, your second transaction will still be waiting for the first transaction to finish before it can finish your second transaction. You can get around this if you open a brand new browser in incognito mode/private mode where it will allow a user to run 2 transactions in parallel instead of just one. Script: //------------------------------Start Code---------------------------------------

// -- GlideHistorySet will accept either a GlideRecord object or (table,sys_id) as parameters. // -- For dynamically fetched records, you can use the below or GlideRecord Query to fetch multiple and iterate //var gr = new GlideRecord('incident'); //gr.get('number','INC000123'); //var hs = new GlideHistorySet(gr); //var sys_id = hs.generate();

var hs = new GlideHistorySet('incident','82cd9e8d2bb669c083845b5fe8da15c2') // var sys_id = hs.generate();

//----------------------------END CODE----------------------------------------- Solution Three: Use the same code above on two areas:

a) On a scheduled job, so it executes once a month

b) On a 'async' business rule to execute every time there is an update on the record that has too many audit records