2015-12-30 09:44 AM
In WFA 3.1 I was testing out WFA approval points this afternoon and noticed an odd behavior. I submitted a workflow using an Operator-level account, then rejected the workflow with an Admin-level account, and was able to resume the workflow as the original Operator account.
It seems the approval point, once satisfied in one way or another, is not checked again when the workflow is resume by an operator. Am I understanding approval points incorrectly or is this the expected behavior? I'd really like to put some hard-stops in place for decomissioning efforts and other potentially disruptive actions.
I've uploaded my basic workflow showing an example goal. Here's a screenshot showing what I'm seeing when testing the workflow out.
Solved! SEE THE SOLUTION
2016-01-03 04:12 AM
This is a known bug in WFA and there since long time. I can suggest you a workaround to get away with the problem you are facing. Its really simple and easy to use.
On Execution status page, there is a button next to "Reject & Abort" called "Clean Reservation". If you press that the reservation of this job will get removed and now the job can't be resumed.
So the approver who planned to reject a workflow in "waiting for approval" after rejecting and aborting the job, can take care to press the "Clean Reservation" button after that, then this job can't be resumed any more.
You can do the same from WFA API as well.
Now cleaning reservation can have some impcat, but its limited to DataSource acquistion.
2016-01-05 06:27 AM
Thanks for the helpful information as always Sinhaa. This workaround should work for the time being.
Do you know if there's any plans to fix this bug in the near future?