SNC Approval - Reset Conditions: not working as expected

[Dan Berger]

We are using the SNC Approval - Reset Conditions Business rule and it is failing when trying to get a lock on the record.  We use this function for a UI action that resets the Change to new (status).  We have a three-tiered approval structure where approvals go to the user's manager, then a group approval, then a Change review board approval.  If the Change is reset to new after any of the approvals have been made, the approval workflow needs to be restarted.  If it isn't restarted, then the user could request approval again and it would skip through any previous approvals.

The OOB script waits 50ms to make sure that the record is locked.  This would be an easy 'fix' to just wait longer, but I need to make sure the work actually gets done.  There is no corresponding ELSE (or error handling) that would handle the case where the lock could not be established, so the function does nothing. 

I have considered creating a loop that would try to establish a lock for up to 30? seconds, but I would need the function to fail and abort the update if it reaches the time-out.  I have tried to use current.setAbortAction(true); but I think it is out of scope.

So how important is it to lock the record?  The comments in the script indicate that it could trigger a second reset while the first is still in progress, but that does not seem likely.  I could skip that part all together.

I am also thinking about not trying to abort and just doing the work if the lock can't be established. 

Any advice on how to handle this?

[Michael Fry1]

We're using this business rule, option 2, as well without issues in our Madrid instance. We have a UI action that basically moves the State back to Draft and that's the trigger for the BR to run.

Where are you seeing the lock on record error? When do you see it?

The alternative is to use the Reset to New ui action but that requires your workflows be named exactly like out of box names.

[Dan Berger]

We are experiencing some network latency and are seeing a lot of database calls timing out.  We are working on tuning the system, but in the mean time, I came up with this solution and it seems to be working.  The issue was that the command to restartWorkflow and CancelApp WorkFlowApprovals were being sent, but not actually completing consistently.  If I validated that the lock was obtained, it seems to work consistently.

A few notes:  

We run this BR on Reset to New UI action and with a scheduled script that runs hourly.  The SS checks that the Request was approved before the start time (when the start time is an hour away).  If the Request wasn't approved in time, then it resets it to new.  If it fails, it will try again in an hour.

     The job was being run by system Administrator, so it was messing with the security rules.  I created a separate account (ChangeControlAdmin) that just had the ITIL role.  This seemed to calm things down a bit.

I added a check to see if the lock was actually created.  If it is created, then the rule runs as expected (OOB).  If the lock is not created, it does nothing but alert the user.

[Michael Fry1]

Have you tried using the baseline UI action: Revert to New?

[Dan Berger]

We are using that UI action that calls this script.  that way, users can revert to new manually and will receive the error message if the lock is not created.  The script is called when the user changes the start/end date as well.

The issue we were seeing was that the approval workflows were not reset--the script cancelled the approvals, but it didn't reset the workflow to not yet requested.  When the Admin user account or any developer with the admin role executed the script, it would pass through the approval process and register that the user approved the Request!?  That's how we knew the approval workflow wasn't completely resetting.

This seems to be working now, we haven't seen that issue since we implemented the updates.