Post Incident Report (PIR) failing to generate | TroubleshootingIssue The following knowledge article provides steps on triaging an issue when a post incident review report fails to generate after a security incident is closed. When a security incident is closed a PDF generated report should be attached to the security incident. This can fail if an instance has its sys_audit table on table extension. An error that may be generated from the logs may appear as: 2019-07-22 10:58:30 (903) Default-thread-8 723C7365DBB2FB405A485055CA961902 txid=958d3769dbb2 WARNING *** WARNING *** Evaluator: org.mozilla.javascript.EvaluatorException: GlideRecord.setTableName - empty table name (sys_script_include.c4fdd0a5df73310068c32df36bf2637b.script; line 539) EvaluatorException(JavaScript evaluation error on: (function executeRule(current, previous /*null when async*/) { var pir = new sn_si.SecurityReviewGenerator().generate(current); current.pir = pir; // Need to be an after BR so as to get all history line // setWorkflow false as no necessary to trigger recursive BR after update current.setWorkflow(false); current.update(); if (current.state == 3) new sn_sir_core.SecurityIncident().pirToPDF(current.sys_id); })(current, previous); ) Additionally, if a post incident report fails to generate outside of this error it can still be caused by the same issue if sys_audit is on table extension. The solution is still the same in this case. Procedure The PDF generation is called from a business rule called Generate PIR When in Review and Close in the business rule there is a call to a method from a script include called SecurityReviewGenerator. In the script include, a user/admin can comment out line 76 to successfully generate the PIR report. The issue occurs because the script include has issues accessing the sys_audit iterator when an encoded query has too many OrderBy methods. This is expected behavior for sys_audit tables which are on table extension and there is no fix outside of commenting out the line entry specified. //auditEntry.orderBy("fieldname"); Applicable Versions All (As this requires the user/admin to make a modification to an OOB script include, it should be carefully noted for review during upgrades as any change to the script include will not be applied to the script include. The changes will need to be reviewed and then merged)