Alert creation intermittently fails with system logs showing "FAILED TRYING TO EXECUTE ON CONNECTION glide.4 (connpid=3333917): INSERT INTO em_alert"Issue Event Management Alert creation via scheduled job intermittently fails. If you navigate to System Logs>Errors you may see the following logs: FAILED TRYING TO EXECUTE ON CONNECTION glide.4 (connpid=3333917): INSERT INTO em_alert (`initial_event_time`,`short_description`,`acknowledged`,`event_count`,`u_close_key`,`description`,`source`,`sys_updated_on`,`type`,`number`,`sys_id`,`sys_updated_by`,`metric_name`,`sys_created_on`,`sys_domain`,`sn_num_work_notes`,`correlation_group`,`u_entity`,`state`,`message_key`,`sys_created_by`,`severity`,`last_event_time`,`resource`,`cmdb_ci`,`last_update_time_by_event`,`sn_services`,`group_source`,`sys_mod_count`,`is_group_alert`,`classification`,`initial_remote_time`,`kb_url`,`node`,`correlation_rule_group`,`last_remote_time`,`flap_count`,`additional_info`,`flap_start_window`,`event_class`,`work_notes`,`category`,`u_maintenance_reason`,`maintenance`) VALUES (2020-12-06 02:38:33','VirtualMachine: ..... Further down on the logs you will also see this Unique Key violation error: Unique Key violation detected by database ((conn=3333917) Duplicate entry '25a28b9b1b3060108bc31fc58d4bcbcc' for key 'PRIMARY') ReleaseAll current releases.CauseThis is most often caused by custom business rules where "current.update()" is used. Per ServiceNow recommended best practices we need to avoid using "current.update()" with any business rule. ResolutionBelow is an excerpt from Recommended Practices in Using current.update() in Business Rules "Details" section: There is almost never a case when the current.update() should ever need to be used in an Business Rule: In a "before" Business Rule, an update of the current record should not be necessary as the record will be saved upon completion of the highest ordered Business Rule. Furthermore, in certain cases, the save may need to be stopped in the chain of Before business rules (with use of the setAbortAction function), and if the record has already been updated, data may have already been saved which would normally be an invalid save by the logic of the Business Rule. In an "after" Business Rule current.update() should also not be used. Any action that might be performed in an After Business Rule can usually have been added in a high ordered Before Business Rule, eliminating any need for an explicit update() function call. In addition, updating in an After Business Rule will cause all Before Business Rules to run again, which, as mentioned previously could cause performance processing issues. An "async" Business Rule is, for this discussion, essentially the same as an After Business Rule. It is simply a Business Rule that executes sometime after the actual record is saved, but not in the user's current session. As in a standard After Business Rule, any updates or changes to field on the current record that could need to be called in this Business Rule should be able to be called in a Before Business rule without the need for a current.update() function call. Not only should the current.update() function not be used in a "query" type Business Rule, it actually cannot be called and will generate an error if called in this type of Business Rule. The reason for this is that, at the time this Business Rule is called, upon the initial query of a list or collection of records, there is no concept of a "current" record. A "display" Business Rule is run when the record first is displayed on the screen and is usually used to populate temporary, internal variables with some values that may not be accessible once the form for the record is actually fully loaded. As a general rule, you should never have the need to save the record immediately upon display of the record, and doing so will call the usual chain of Business Rules associated to that record. Thus, there should rarely, if ever, be the need to actually use the current.update() function call in any Business Rule. This would also apply with a client script that might be called through a Business Rule. In any case in which the use of the current.update() can be avoided in favor of another method to accomplish what is needed, the alternative option should generally be used due to the known potential for performance issues that night occur when using this function in any Business Rule. Occasionally, an existing Business Rule may be found that uses the current.update() function, sometimes even an out-of-box object. These are the rare exception and if another method can be found to perform the same task, that method should probably be used instead.