Auto approval business rule does not advance workflow

[matt v_]

Hello,

We have a before insert/update business rule in place on the sysapproval_approver table to check if approver is the person who initiated the request (document_id.opened_by), and if so will change the state to 'approved'.  I can't imagine why this would not be default behavior, but nevertheless, this rule is working as intended.

Most of our approvals are fired from HR Case workflows, and the issue here is that even thought the approval request is updated correctly, the workflow gets stuck as though it is still waiting for that approval.

When we know of a case with this issue, I can Nudge that workflow and it moves to the next step.  We also found that if anyone makes a change and updates the case, this also triggers the workflow to move along.

I would prefer to make some small edit to the business rule if possible.  My first thought was an update() command, but a little reading showed that to be a really bad idea.  Is there anything else I can add to the script after updating the approval state?

A workaround (haven't tried yet) that seems like a poor band-aid would be a scheduled job that nudges workflows daily.  That just seems really silly to have to do.

Any suggestions?  Or is there even another, better way to accomplish an auto approval if the approver is also the requester?

Here's the script for reference (not created by me).  It may seem a bit convoluted, but this is due to the fact that some of our workflows are set to pre-generate tasks/approvals, so we don't want to change the state of an approval if the prior steps haven't been completed yet.

(function executeRule(current, previous /*null when async*/) {
	var autoApprove = false;
	
	if (current.operation() == 'insert' && current.approver == current.document_id.opened_by) {
		autoApprove = true;
	}
	
	var sameApproval = new GlideRecord('sysapproval_approver');
    sameApproval.addEncodedQuery('approver=' + current.approver + '^sysapproval=' + current.sysapproval + '^state=approved');
	sameApproval.query();
	
	if (sameApproval.next()) {
		if (current.operation() == 'insert') {
		  autoApprove = true;
		}
		if (current.operation() == 'update' && previous.state == 'not requested' && current.state == 'requested') {
			autoApprove = true;
		}
	}
	
	
	// Add your code here
	if (autoApprove) {
		current.state = 'approved';
	}

})(current, previous);

[matt v_]

Thanks, we do have that OOB business rule and it's already active.

And I get what you're saying about the split workflows, and we do that to some extent.  Some of our workflows are done this way, but not all.  I prefer the idea of a single rule so that we don't have to make 2 workflows for every one (or add an extra workflow call to any workflow that needs approvals).  After all, why should anyone ever need to approve their own request?

[Chris Sanford1]

One thing you might try doing is updating the parent record. You could do that in a GlideRecord object that points to the parent with setForceUpdate(true) (Global scope only) followed by update(). If you post a work note or comment on the parent record after approving does that update advance the workflow? I've seen that kind of behavior happen before.

[matt v_]

Your guess is correct.  Any update, even a comment, on the case or approval will allow it to move along.

Is it OK here to use update() since we're updating a record on a separate table from the rule itself?

[Chris Sanford1]

Yes that is fine. Something like this, at the end of your business rule:

var gr = new GlideRecord('task');
if(gr.get(current.sysapproval)) {
   gr.setForceUpdate(true);
   gr.update();
}

[matt v_ · Accepted solution]

That didn't seem to work, and it also resulted in a 'unique key violation' for duplicate entry of the approval Sys ID.

After all the testing back and forth, and trying different ways of doing the same thing, I ended up adding a 2 second wait timer at the beginning of the workflow and this resolved the issue.  I was hoping to avoid that, but it seems that the first few steps are just happening too quickly.

Thanks for all the suggestions!