Symptoms

---

The notification event "request.approval.inserted" is not triggered for approvals on request table when the approvals are generated from the workflow for the first time.

 If the workflow has second approval activity, it triggers the correct event "request.approval.inserted" 

Release

---

Kingston

Cause

---

The business rules which triggers the related events on approval table is "Approval Events (Task)". Going through the script we can notice that if the class is "request", the expected event is "request.approval.inserted" but this is not happening when workflow creates approval on request table this is because at the time, Request is not yet available when workflow runs. Therefore, it fired the "approval.inserted" event instead of "request.approval.inserted" but in case if the workflow has second approval activity, it triggers event "request.approval.inserted" as it already has a Request. 

Resolution

---

The business rule is updated on London version and this issue is resolved in it. 
A simple workaround which can be used is that, replace line 2 from 

var task = current.sysapproval.sys_class_name;

to 

var task = current.sysapproval.sys_class_name || current.source_table; 

or replace line 2, line 7, line 12 from 
var task = current.sysapproval.sys_class_name; 
to 
var task = current.sysapproval.sys_class_name || current.source_table; 

One more thing to note, Once if below customizations are made then the upgrade process automatically skips changes to these objects.To Overwrite customizations during an upgrade Please refer below doc:
https://docs.servicenow.com/csh?topicname=t_OverwriteCustomizsDuringUpgrades.html&version=latest