Workflow Skipped Approvals result in… Approved?!

Hi,

Nice article.

Although, in my opinion, I lean towards the camp of people that believe that this is "set up correctly" as is, OOB. The reason being...if the approval is skipped for whatever reason, then it is deemed not necessary. If you have an approval user or approval group set there and poor system administration leads to that group having no members...or the approval user being inactive, then there's a bigger discussion to be had and it shouldn't be held up. I can see either side on this, but for me, I'd say, if it's skipped, then it's not needed. Same as if you input logic to check and see if a specific user had already approved a prior step, you'd most likely want to skip it, meaning not needed/necessary. Sure, you could just change the skipped to approve using your method per each use case, but the overall picture is that if it's skipped anyway, it's not needed. So, if it auto-rejects, which is the negative/worst outcome, due to poor administration, then the user is penalized and it could go unnoticed for quite some time as to why that is happening. So then users get punished.

Either way, nice article and coverage of that. Just throwing in my 2 cents.

Take care! 

besides a user being Inactive or a group without members are there other common scenarios that would cause the Assess skipped result? i'm troubleshooting that right now, had checked both of those already and struggling to find why the Assess approval skipped

Hi,

Is there any script involved? Is it looking at hard-coded sys_ids? Do those sys_ids actually match where it's supposed to go? Not sure of all the details on your end, but that's normally what I've seen. Some sort of accidental administrative type setting like that or the script is not necessarily causing it to break, but it's still passing through.

Can you check and see if there's anything in the logs?

Did this randomly just start happening? Did anything change recently to cause that? etc. etc.

Please mark rely as Helpful, if applicable. Thanks!

thanks for that Allen, the policy input for the approval assess task in workflow is just as it is OOB (in looking at a PDI) so no modifications to the code there.

below is what i see on at least two change requests so far that we've found to have skipped thru the Assess task, they both said no Decisions matched. which is really puzzling as it just started happening and i cant reproduce in our sub_prod. no hard coded sys_ids. 

i've doublechecked the decision that the pertinent group is active, and in this case is a group mgr approval so i checked that the group had an active user set as mgr. its just really weird. i'll keep digging.. thanks for your advisement

What about a method to check for the result = SKIPPED and in that case <do something> (maybe pause the workflow and notify some team to handle the REQ approval manually somehow)  ? 

You can just add an additional Skipped transition. All details are provided in the article, so you should be able to do that.

Kind regards,
Mark

Thanks Mark, i'll check that out!

Hey Allen,

What's the best practise in handling such scenarios where user is made inactive should we allow workflow activity to skip or write some logic and send it to user manager ? Also what about requests and approvals assigned to user who got terminated should we cancel requests or again reassign them ?

Thank you

Hi Bharath,

So normally, best practice would be to never really assign approvals to a specific user, if you can help it. If it's a scenario where it's their manager, so you're dot-walking from requested for user to their manager and the manager is now inactive and your HR or whatever hasn't changed that user's manager or it frankly hasn't been assigned, then yeah, the flow would skip it. You could either use what @Mark Roethof mentioned above and route them to rejected (though this could be perceived as a poor user experience and doesn't necessarily tell them "why" it was rejected) or bake in a check for their manager to see if they're active or not, if not, then proceed up to that manager's manager and continue walking until you find an active user (although this can get a bit wonky when you report to someone who then reports to the CEO)...so you'd want to create a process here for what to do. Does it go to manager's manager up to a certain title level? Or one attempt and if inactive it goes to a "catch-all" group for approvals who decide 'x'.

So the above check could be done within an if activity, for example, before the approval activity.

For current requests that are sitting out there and then the approver was terminated, you have a few options:

1. Rejected the request and let the user know to resubmit once their new manager has been assigned (this is the worst option in my opinion)
2. Have fulfiller/someone reach out to the new manager and get their approval for this user's request and then approve the request manually, but leave a note on the approval with a copy of the email or chat showing the new manager approved
3. Attempt to clear approvals from the workflow and essentially restart it after the new manager has been correctly set for this user so that it processes "officially"

I've seen all 3 methods used and depending on how big your org is, #2 may be feasible or not.

Anytime a workflow/flow has a user as an approval, I always get a bit weary about it and would recommend thinking through: what would happen if this referenced user is not filled in (so no manager at all?), the user is inactive, the user was active, but is now inactive before approving, etc.

Anyways, that's my 2 cents on all this.

And to circle back and ensure this is said...what Mark has suggested is the best option to ensure approvals aren't bypassed. Which is the safe play. So I'm not going against what he wrote here, I'm trying to cover this from an end-user perspective. But from a security and sys admin perspective, I would 100% agree with not allowing approvals bypassed simply because the skipped outcome occurred. I'm suggesting we try to account for that and not let it happen in the first place.

Please mark reply as Helpful, if applicable. Thanks!

 I have found an underlying phenomenon in ServiceNow. It has to do with how the system weights approvals. When a manager approves, then usually the approvals that follow are skipped automatically. The only way to counter this is by having a user with the same "weight" in the system follow the approver, i.e another manager. 
Although I have shown below a Flow, the same logic of weights applies to both workflows as well as in flows. 
to bypass this issue: 

in flow designer: you must look up the records of the next approver in the sequences AND they must be a manager in the system to trigger additional approvals.
then ask for approval from the previous data pill where you looked up the additional approver, approvers (if you use a for loop and a custom action). 

The scope of my answer applies to both workflow as well as flow designer. 

in WorkFlow, you must ask for approval a second time with a different manager, even if it is just the manager of a group. By being a manager, the system will recognize the validity of requesting approval, and the approval will be requested. 

If my answer helped PLEASE upvote my answer to help other people facing the same issue. 

 

@Allen Andreas @Mark Roethof I am using Process Automation Designer to create a workflow. If I am rejecting an approval step, the activity state changes to Skipped. When I change the approval step to Approved, the activity state still remains Skipped.