Change request approvals unexpectedly reverting to 'Requested' following rejection - why?

[jas101]

Hi guys, I'm having some difficulty with change request approval records following rejection/workflow reset.

So if an approver (from a group approval) rejects a change, other approvers in that same approval group go to 'No longer requested' - this is expected behaviour I believe.

However following the State resetting to 'New' (again expected as per workflow), and a re-request of approval, these same approval records are reverting back to 'Requested' which I believe is unexpected behaviour given that new approval records for these same users are also being re-added as 'Requested' (again I believe this latter part is expected).

Any ideas why this is occurring and how we can ensure the original approval records remain on 'No longer required' as we'd expect? Many thanks.

[Michael Ritchie]

Out of the box once an approval activity starts, it checks for any pre-existing approvals in a No longer required (not_required) state and moves it back to requested.  The idea there is if a workflow restarts via a rollback then existing approvals reset and become required again.  From a change perspective this is important because if a change is sent back to the requester and modifications to the change are made, all the approvers need to reassess the change.

So this said, are you saying that all the custom work we discussed prior happening in the approval coordinator are duplicating approvals?  This situation likely needs to be considered in the scripts that set the approvals to look for existing and not recreate.

I am out on vacation next week so I won't be able to help further until I return the following week.

[jas101]

Hi Michael, hope you're having a great vacation. This week I have established that the issue I'm seeing is related to this known error: https://hi.service-now.com/kb_view.do?sysparm_article=KB0622125

Basically on versions prior to Jakarta (we're Istanbul) the OTB 'disassociate approval record' activity script has a problem with workflows that use approval coordinators. The workaround is just to use 'Rollback' activity instead. It's frustrating as our plan is to upgrade SN shortly after our change overhaul anyway but I don't think I can swap this round annoyingly. Oh well. I will likely just rejig the change workflows again once we've upgraded the platform I guess.

Thanks for your input/help on this.

[Michael Ritchie]

Daniel, bummer on the resolution.  Here is an idea that may buy you some time... the solution to the problem associated to the KB article is edits to the out of the box "WorkflowApprovalUtils" script include.  I have compared the Istanbul and Kingston versions and there are quite a few changes.

• You could get a Kingston (or whatever version you plan to upgrade to) personal dev instance via Developer program
• Grab the script from that version's WorkflowApprovalUtils script include
• Edit your instance's WorkflowApprovalUtils and save the new script
• Test to see if that resolves the issue.  Be sure to view the logs table to ensure there are no errors with applying a newer version.

Assuming success and once you are ready to upgrade...

• BEFORE you upgrade your dev instance, navigate back to the WorkflowApprovalUtils script include and using the versions related list, revert to the out of the box version.
• Then upgrade.  This will ensure that you are back to out of the box and this script include will upgrade and not skip.
• Make sure you revert to OOB in each upper instance prior to upgrading - this can be done with an update set prior to executing the upgrade.

[jas101]

Thanks for this idea Michael, I'll take a look to see if updating the script include resolves the issue.

[jas101]

Hi Michael, so an update... this worked... kind of!

As a result of 'borrowing' the code from Kingston version, I was able to prevent the situation where approval records are set to 'Requested' (incorrect behaviour) AND new approval records for the same approvers are created (i.e. the original approval records were staying as 'No longer required').

However thinking I finally had this all cracked I realised there is still a situation where the workflow falls down somewhat and this is regarding the manual approvers (we have a 'Manual Approver' activity stage within the approval co-ordinator because of the need to always allow change requestors to add manual approvers as well as the 'automated' group ones).

In summary, it's apparent that following a rejection, when approvals are reset / rolled back (oh yeah btw, after all the above we have decided to use simple rollback instead of disassociate existing approval records and create new ones!), although all the approval records are reset to 'Requested' (when 'Request approval' is re-clicked), the requirement for the manual approvers to actually approve is not there as seen by the workflow showing that manual approval activity stage as blue i.e. satisfied in terms of progressing the workflow (all the others are green indicating they're waiting approval). I have found that the only way to ensure the manual approvers are required is to manually remove the manual approvers, save, readd them back and then manually set them back to 'Requested'!

This seems so clunky right. As such am just wondering whether you have any suggestions (other than not using manual approvers which has been made clear to me this is not an option!) as to how I can make this whole process smoother for change owners who have manual approvers added to their changes.

I'll likely post a new question for this shortly, in which case I'll edit this reply with it or update this thread.. here it is:

https://community.servicenow.com/community?id=community_question&sys_id=9667db06dbc42fc0feb1a851ca961961

Thanks a lot.