Approver changing answer breaks the approval process

[ed475]

I have encountered the following scenario which breaks the change process leaving it stuck in assess/auth:

Approval rule: one approver from each group or any reject - created by 'ask for approval' flow action

• lets say we have 2 group approvals pending
• user_1 from group_1 approves the change - all other group_1 users approvals are set to 'no longer required'
• user_1 changes their approval to 'not yet requested' - done accidentally and not noticed.
• user_2 from group_2 approves the change
• all groups have now provided an approval response - the flow processes this
• because one response is neither an approval or rejection ('not yet requested') the ask for approval result is set to 'cancelled'
• As there is nothing to handle this the flow ends but the change does not transition states forward or backwards
• The change is now stuck in assess/authorize with approvals and flow completed - there is no way to 'unstick' this change record.

I can add a check to all the assess/auth flows to see if the 'ask for approval' result is neither approve or reject and take some action at this point.  However, it is a lot of work just to try to catch a very unlikely scenario so it doesn't feel like a great solution.

Considering this scenario - how should it be handled? What is the correct approach to ensure the change/flow cannot get into this state? Can you provide any other insight?

[Itallo Brandão]

Hi ed475,

You are absolutely right: Adding error handling logic to every single flow to catch a user error is not the scalable solution. It creates technical debt and doesn't solve the root cause.

The Root Cause: The issue is not the Flow logic; it is a Data Integrity issue. Functionally, an approval record (sysapproval_approver) acts as a "State Machine". Once a user transitions to a terminal state (Approved or Rejected), the system should never allow a user to manually transition it back to Not Yet Requested or Requested. That is a backward movement that breaks the process logic.

The Correct Approach: Lock the Door Instead of handling the crash in the Flow, you should prevent the user from causing the crash. You can do this with a simple Business Rule (or ACL) that forbids this specific state transition.

Here is the recommendation to fix this globally:

Solution: Data Integrity Business Rule

Create a Business Rule to prevent users (even accidental clicks or List Edits) from reverting a decision.

• Table: Approval [sysapproval_approver]

• When: Before Update

• Condition: State CHANGES TO Not Yet Requested AND State CHANGES FROM Approved (You can also add Rejected if needed).

Script:

(function executeRule(current, previous /*null when async*/) {

    // Prevent moving backwards in the approval process
    if (gs.isInteractive()) { // Allows system/scripts to do it if necessary (e.g. Rollback), but blocks users
        gs.addErrorMessage('You cannot revert an Approval decision back to "Not Yet Requested". Please contact the Change Manager if a restart is required.');
        current.setAbortAction(true);
    }

})(current, previous);

Immediate Fix for the "Stuck" Record

To unstick the current record without deleting it:

1. Open the stuck Change Request.

2. Use a Background Script to force the state to a Draft or Canceled state, or restart the flow.

   • Option A (Nudge State): gr.state = 'new'; gr.update(); (This might re-trigger standard flows).

   • Option B (Kill Flow): Go to Process Automation > Active Flows, find the context for that record, and cancel it. Then manually move the Change State back to "New" to restart the process properly.

Summary: By implementing the Business Rule, you ensure the Flow Action never receives that invalid "Neither Approved nor Rejected" data set, solving the issue for all future flows instantly.

If this architectural approach helps you solve the problem globally, please mark it as Accepted Solution.

Best regards,
Brandão.

[lauri457]

You have most likely misconfigured the approvals in your flow or you have customized automation in approval related records. 

1. If you are using group approvals user1 approving should set their group1 approval to approved
2. Editing user1 approval has no effect on group1 approval
3. user2 approves
4. all group approvals approved and flow progresses

Recreated your scenario in my pdi, this is not expected behaviour with the ask for approval action

I would suggest using change models and change approval policies while using the oob flows with necessary configurations to match your change process. Also how is a user changing the state of their approval accidentally? If users are making unwanted changes repeatedly it is good to revise the UX/UI and/or provide training 

[ed475]

Thanks this is useful insight. You are correct, although user_1 changes their response it does not update the group approval, so in the end all groups have approved. However, the approval will still report it's state as cancelled.

When I also try to recreate this using a change flow on a PDI I get the same results, but if i change the approval response from approved to 'not yet requested' I get even stranger results.
1. set up ask for approval in change flow

 2. user approves for CAB group

3. CAB group set to approved - Service desk is still requested

4. change user's approval to not yet requested - all other users approvals from both groups change to 'no longer required'

5.  Service Desk group now marked 'no longer required'. CAB is still approved:

6. The approveal flow reports the approval state as CANCELLED.

7. change is 'stuck' in Assess with no pending approvals - the assess flow is completed

 

 

[lauri457]

Sorry you are right I didn't try with the not yet requested state using the ask for approval action, it seems that this action does not play well with your scenario. And the action is implemented in java so it's not possible to edit. It does make some sense that it "fails" when an illogical state change happens.

However if you just use the change approval policies your scenario won't break the flow. The approval in not yet requested state will hold up the flow with the "apply change approval policy" action but it can be updated back to progress the flow as expected. 100% recommend change models and approval policies anyway

I would try and find a way to fix this from a process point of view rather than platform although I do see merit in restricting the state from being manually moved back to not yet requested.