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]

Can you please post a screenshot of your workflow?  Is this a case where you are moving a change back to a starting state so additional information can be entered and then it is resubmitted for approval?  If so it is expected behavior for approvals to "reset" and be re-required.

[jas101]

Hi Michael, thanks for the reply. Screenshot of relevant part of workflow below. This is regarding where State is set back to New but I believe OTB the new necessary approval records are just re-created (and set as 'Requested'). We are seeing this happen but we are also (unexpectedly I think) seeing the group approval records that were set as 'No longer required' revert to 'Requested' also, meaning these approvers now have two 'Requested' approval records each. Not sure if it's to do with the 'Disassociate approval records' activity stage below but we have not amended this at all from OTB.

Thanks for any help in advance.

Replication steps below

1) Raise Normal change, fill out other required info in change and request approval on change to move to State 'Assess'
2) Reject as one of the approvers and observe that that approval record goes to 'Rejected' and any other approval records of approvers in the same approval group go to 'No longer required' and State sets back to 'New' as per workflow
3) Click 'Request approval' again and observe that new approval records get created (expected) but the old/existing approval records that were on 'No longer required' change to 'Requested' also (not expected)

[Michael Ritchie]

The out of the box way to reset approvals is via the rollback activity. I see one in the Workflow but it doesn’t appear that the rejection from the approval coordinator goes to this activity. Rollback will move any existing approvals to no longer required. Have you tried a rollback?

[jas101]

Hi Michael, I've compared with my Developer instance (OTB - screenshot below) and it looks the same as we have it - the only part we updated in the above workflow is swapping out 'Technical approvers' approval group for the 'Approval co-ordinator' (because of the approval requirements you kindly helped me with prior).

From what I can see it looks like 'roll-back' gets used when a change is put on hold but if a change is rejected than behaviour is to reset State to New, 'disassociate approval records' and wait for State to go back to Assess (i.e. when re-click 'Request approval' happens).

I have a hunch that for reasons I do not understand using the Approval co-ordinator has had an affect on this reset part of the workflow i.e. where it should dissociate current approval records (so to maintain a history of the rejection) before re-adding the necessary new approval records once the workflow is restarted. As mentioned these new approval records are being re-added but we are finding that unlike OTB, the old approval records that were on 'No longer required' following the rejection are reverting back to 'Requested' when they should be staying on 'No longer required'... as otherwise those folks have duplicate 'Requested' approval records.

Thanks again for any help.