Problem with state changes in approval levels in Policy exception

[AlineGratiA3017]

Hi GRC experts, 
                       We have configured 2 approval levels in Approval configurations for Policy Exception in PDI. However, the requirement is When any approver from the first approval level rejects it, the second approval level  should move to No Longer required state. But in our case, we still see the state as Not Yet requested. We have found out an OOB flow called "Dynamic Final Approval for Policy Exception" is responsible for this state transition. Inside that we have a sub-flow called "Dynamic Approval for Policy Exception" which has the exact state transition to be updated as No Longer required for subsequent levels when one level got rejected. Yet the state transition is moving to Not yet Requested instead of No Longer Required. Can anyone help on this ? I have attached certain evidences of the OOB sub-flow and the record approval levels in screenshot.

[Dan_Junqueira]

Hi @AlineGratiA3017 how are you?

Based on your description, this appears to be related to how the OOB Dynamic Final Approval for Policy Exception flow handles subsequent approval levels after a rejection.

Since your second approval level remains in Not Yet Requested instead of transitioning to No Longer Required, I would recommend checking a few things before modifying the OOB subflow.

1. Check the Flow Execution Details

Open Flow Designer and review the execution details for both:

• Dynamic Final Approval for Policy Exception

• Dynamic Approval for Policy Exception

Verify whether the rejection branch is actually being executed and whether the action responsible for updating subsequent approval levels is reached.

2. Validate the approval records and conditions

Check whether the second-level approval records have already been created when the first-level rejection occurs.

This distinction is important because Not Yet Requested may indicate that the approval level was initialized but never activated.

Also, verify whether the update action targets all remaining approval levels or only approval records matching specific conditions.

3. Check the rejection handling logic

Review the subflow conditions and confirm:

• The rejection outcome is correctly returned to the parent flow.

• The subsequent approval levels are identified correctly.

• The update action includes records in the Not Yet Requested state.

• No other flow, business rule, or approval mechanism is overwriting the expected state.

4. Verify the actual update operation

If the subflow reaches the expected action, check its inputs, record filters, and execution results.

If the action executes successfully but the state remains unchanged, I would investigate whether another process updates the same record afterward.

5. Avoid modifying the OOB flow directly

Since this is standard ServiceNow functionality, I would first reproduce the behavior in a clean PDI with a basic two-level configuration.

If the same issue occurs without customization, it could indicate a product defect or a difference in the implementation for your release.

In that case, opening a ServiceNow Support case with the flow execution details and approval record history would be appropriate.

My recommendation:

Start by checking whether the second-level approval records exist when the rejection is processed and whether the relevant update action actually executes.

These two checks should help determine whether this is an issue with approval initialization, the subflow conditions, or the state update itself.

You can also refer to the official documentation:

ServiceNow – GRC Approval Configurator

ServiceNow – Define Policy Exception Approval Rules

Hope this helps!

If you found this response helpful, please mark it as Helpful. If it resolves your issue, please mark it as Accept as Solution, so other community members facing the same problem can benefit from it.