Lock Down Change Approval

I don’t know of a way to restrict approvals but I have come up with a couple of possible workarounds for you.

Workaround 1: You could set the decision task to a different CSG to move it out of reach for your standard assystUsers. This would likely only work if your approvers and change processors are clearly separated. It might also require you to add some annotation to the parent Action History for audit and transparency.

Workaround 2: This solution assumed that the individual you mentioned in your post is also the affectedUser of the parentEvent. Though the solution would work with reviewingUser, ResponsibleUser, etc. Also, that your workflow looks something like this:

The proposed workaround would be to insert a dynamic authorisation task after the decision (shown below). Set to trigger if the affectedUser and lastActionUser are the same person using the code below (or something similar):

if($new.lastActionUserSC = $new.affectedUser.shortCode,1,$NO_VALUE)

Essentially adding a safeguarding step in case of innocent approval skipping before implementation. This won’t prevent your scenario, and it doesn't stop them from processing both workflow stages. But it does increase the effort required to circumvent process (possibly demonstrating intent) and, gives you a clear line of reporting and audit.

You could combine both suggestions by moving only the authorisation task to a CSG of it’s own to make it impossible to get around.


Let us know what you end up doing. I suspect we have all (if somewhat rarely) had this happen.

Thanks Steve I’ll give the CSG idea a go in Test. Is it me or is this quite a big back door to the change management process. It seems odd that the system provides the ability to simply reassign the approval for a production change.