Approval State Reverts to "No Longer Required" After Setting to "Requested" via UI Action

[VrindaGirdher]

Hi everyone,

I'm working on a custom Expense Management application in ServiceNow, where I'm using a custom table called x_merl4_expense_ma_line_of_items to store expense line items. For approvals, I'm using the standard sysapproval_approver table. Each approval record is linked to a line item through the sysapproval reference field.

I've added a UI Action directly on the sysapproval_approver table. When clicked, it first checks if the manager's remarks field (u_manager_remarks) is filled, and then updates the related line item's state to "Submit for Review" (state = 3). After that, it sets the approval record's state to "requested" and updates it. The script runs fine without any errors and updates both the line item and approval state correctly.

However, right after the update, the approval record's state automatically changes to "No Longer Required". I've confirmed that the parent Line Item is active and not closed or rejected. There's no business rule canceling the approval either.

I'm trying to retain the approval state as "requested" after the action, but it seems like some platform logic or flow is overriding it. Has anyone faced a similar issue or knows how to prevent the system from auto-updating the state to "No Longer Required"?

Any suggestions would be really appreciated.

Thanks,
Varinda Girdher

Varinda Girdher

[VrindaGirdher]

Thanks for your suggestions, and I really appreciate the guidance on best practices.

I completely understand that placing a UI Action directly on the OOB sysapproval_approver table isn't ideal, and using Flow Designer with the "Ask for Approval" action would be a more maintainable approach. However, in this specific case, our process has some unique conditions that made it necessary to manage both the approval and custom table (Line of Items) states through script logic.

The reason for setting the approval state to "requested" was to allow the user to resubmit additional information (like a receipt) after being prompted to "Return for Review". During that period, we need the approval to remain in an active state so that the manager can later review and take final action.

I’ll definitely check for any Business Rules or other logic that could be resetting the state using the script debugger, and I’ll also try using `setWorkflow(false)` to help isolate the issue. If it remains difficult to control via scripting, I will explore migrating the logic into Flow Designer for better visibility and management.

Thanks again for your help!

[daichiTrojan]

I understand the need to keep the approval active, and it's common to wait for certain conditions before proceeding with approval or other logic. We have the "Wait for condition" out-of-the-box (OOB) action for this in FD. However, I disagree that a UI action and scripting was necessary on the OOB approver table. There are always workarounds. If you can specify the unique conditions you mentioned earlier, I can assist better, and this may also solve your approval issue. Building direct logic on the OOB approver table has consequences, as this table has many workflows, business rules, and scripts attached to it.