We’ve had an issue highlighted to us by one of our support teams that a user has assigned a change approval decision task to themselves and approved it.
The particular process assigns an approval decision task to an Approval SVD containing only those users that are authorised to approve a change. We can see in the action history that a user outside this group has assigned the decision task to their own SVD and then approved it.
Does anyone have know how we might stop this just for certain decision tasks? I don’t really want to restrict the “assign internal” action as this would affect a much bigger group of users and processes.
Needless to say we’ve told the user not to do this and we can keep an eye on this but was hoping there is a way to plug this hole. Thanks
Page 1 / 1
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:
Theoretical workflow as it
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):
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.
