Delay Firing of Approval Inserted Event in Workflow

[jmiskey]

We have a workflow that is sending out an Approval.  The "approval.inserted" event is automatically triggering our default approval notification.  However, we are trying to add some custom verbiage to the Comments section of the approval via a "Run Script" action in the workflow.  The trick is, in order to write it to the approval, the "Run Script" needs to run AFTER the approval has been created, but BEFORE the notification has been emailed.

We messed around with adding a "Wait For Condition" (wait for "Approval is Requested") and a "Timer" (for 1 or 2 seconds), and it would work sometimes, but not others.  More specifically, it would always write the comments to the Approval, but not always in time before the Notification email was sent out (so it was "hit or miss" on whether or not the email had the comments).  I then tried removing the timer altogether, but then it wouldn't write the comments to the approval record.

I think what I need to do is to somehow delay/pause the "approval.inserted" event from firing and sending out the email until the comments are written to the approval record.  Is there a way I can do that?

Thanks

[jmiskey]

Yes, it is definitely something that bears watching.

Note that the behavior we are experiencing is in our sub environments (DEV and TEST).  They are both considerably slower than our PROD environment.  So I am speculating that might be part of the problem, and it perform better on PROD.

[Javier Arroyo]

The workflow is not a suitable place for it, nor is faith that execution time discrepancies will work. 

 Depending on your comfort level in the platform, this can be achieved multiple ways.

 One strategy could be to create a mail script that calls a sys_ui_message containing the desired message.

Add the notification script to the template used by the approval email where ever it needs to show up.

 the platform will transpose record fields in the sys_ui_message so that message can become as elaborate as you need them to be. 

Message

<div> ${record.variable} say something</div>

Notification Script

gs.getMessage('approval_inserted_custom_message'); 

template

<mail_script:approval_inserted_custom_message>

I would, however, opt to disable the current email and create a custom version, along with a template, and notification script. Still leverage the OOTB event, no need to create your own.

This will keep OOTB items intact, while gaining customization that performs precisely as if OOTB.

[Kalaiarasan Pus]

Is triggering a custom approval event and configuring a notification, not an option? This seems to be logically the right approach to me.

[Javier Arroyo]

Because the OOTB functionality already triggers an event and sends a notification upon inserting an approval, adding a second event duplicates notifications and effort in such manner: 

 1. OOTB email is fired
 2. Custom event is fired and email triggered.
 3. OOTB email functionality for approval.inserted would need to be updated by excluding approval inserts  now handled by the custom functionality.

The lesser intrusive method that leaves OOTB functionality intact is to deactivate the email, make a custom and adjust as necessary.

thoughs on the selected method:
The chosen method to update the workflow is an unnecessary development overhead that will require a full dev cycle each time a change of text is needed, plus someone with the knowledge to make it. This means dollar signs and wasted time on trivial functionality.

Work that can be handed to an admin to change on the fly should never be placed on a dev cycle. What happens next time the message needs to change?

[jmiskey]

We are trying to limit the number of approvals and customizations we have, so things don't get out of hand.  

I got help from one of our senior programmers who in addition to changing the switch to an if/else, made some other structural changes to the Run Script code.  He structured it similar to another process that has been working successfully for a few years, without issue.  So far is has been working for many tests that we have run at different times of the day.  So I think we are going to go with that for now.

But I am definitely bookmarking this ticket, in case we run into issues at some point down the road.  Then we have lots of options to test.

Thank you all for your valuable input.