Metric Instance record incorrectly calculated with metric events processed before audit record is createdDescriptionSecurity Incident metric "Time to Identify" does not seem to be correct. When looking into the validity of the "Time to Identify" calculation for the SecOps module dashboard, a high number of durations calculated as "23 hours 59 minutes" when the Start time is actually 1 second after the End time in the Metric Instance table or negative 1 second duration. The issue affects different Metric Definitions (i.e. End time seems to be 1 sec before Start time) spanning different applications in the platform. Various metric records which intermittently receive incorrect values, i.e the metric value record is the same as the previous metric value. When this occurs the one common factor is that the metric_instance record is created before the associated audit record.Steps to Reproduce Add the column u_supplier string the incident tableCreate a field duration metric definition using the u_supplier fieldCreate a new incident and populate the u_supplier field with 1Create a before business rule with the order 10001 which executes the following statement gs.sleep(15000);Amend the u_supplier field on the incident you created in step 3 to have a value of 2 and save record WorkaroundAfter carefully considering the severity and frequency of this problem, and risk of attempting a fix, it has been decided to not address this issue in any current or future releases. We do not make these decisions lightly, and we apologize for any inconvenience. When the metric is created, it relies on audit. If the audit is not created yet, then the metrics can be miscalculated. It is a timing issue, so the workaround is to change the execution order of the "metrics events" business rule to run last (i.e. priority=999):/nav_to.do?uri=sys_script.do?sys_id=35f9861dc0a808ae00ecf631cc51888cRelated Problem: PRB967408