Rule to autoapprove a step if approver has already approved in another step?

[Jason Freeman]

Pretend you have two approval steps: "Waiting on VP Approval" and "Waiting on Supervisor Approval."

Sometimes these are the same person.  For example, if you work for the VP, he/she is your supervisor and the VP, making it where the VP has to approve at both steps.

We have the Automation for JSD plugin.  Is there a way to make a rule similar to this logic?

Triggered when an approval is required: if the approver has approved in a previous step, autoapprove this step.

[MK]

You may use script Runner or JWT for this based on the approver field values.

[Petter Gonçalves]

Hello Jason, 

Unfortunately, after searching some time on our marketplace and community articles, I've not found any possible plugin/feature that could give you this functionality, however, I would like to better understand when you would face this scenario so we maybe provide you a different workaround for it.

You said: 

Sometimes these are the same person.  For example, if you work for the VP, he/she is your supervisor and the VP, making it where the VP has to approve at both steps.

Analyzing the explanation above, it seems that the Customer department will define if the same person is the approver on both workflow steps. Is that correct?

For this Scenario, I would create a customized workflow/request type for each department, adding/removing the approval steps based on the customer type or at least using a different way (Transition and Status) for this customer.

Another option would be to use a custom field in the Request type called "Department" and use your automation to automatically approve/transition the issue through the steps based on its value.

Let me know if one of these options would work for you.

[Jason Freeman]

Thanks for the reply.  I don't think that will work in our situation, but I'm not exactly sure because I'm relatively new to Jira.

Let's go back to my example: "Waiting on VP Approval" and "Waiting on Supervisor Approval."

The Vice President (VP) of our organization is always a single person; it doesn't change. No matter who puts in the request, the VP is always going to be the same person.  So, the VP is a hard-coded value that never changes.

Unlike the VP, the Supervisor changes per person.  My supervisor and your supervisor may not be the same person.  Therefore, the requester types in the name of his/her supervisor in a User Picker field.

Most of the time, the user in the VP step and the Supervisor step are different people.  In these situations, no problem exists.

But if you work for the VP, then the VP step and the Supervisor step are the same person.  Once your supervisor approves it, it still goes to the VP.  Well, the VP is the same person, so this means that the VP has to effectively approve the request twice: once at the Supervisor step and once at the VP step.

This is only one example.  Another example with three steps: a VP step, a Data Custodian step, and a Supervisor step.  In rare circumstances, these are the same person.  In this circumstance, the VP would have to approve the step three times: at the VP step, the Data Custodian step, and the Supervisor step.

There are so many unusual circumstances that can occur.  We have a few workflows where, in theory, a person would end up needing to approve at five different steps.

The easiest way to remedy this would be to have an overall rule for a workflow that says something like, "Upon each transition, if the current step is an approver step, check to see if the approval step contains users who have already approved this issue in a previous step.  If so, automatically approve this step."

This would fix the problem no matter how many times the a user is requested to approve steps in a workflow.

[Jason Freeman]

So far, we have worked around this problem by creating a bunch of rules that compare the value of the current approval step to a previous step.

Example: If ("Vice President" = "Supervisor") { Autoapprove This Step } 

Those rules technically work, but they are getting out of control and too complex.  We are running into situations we never anticipated, and some of our rules are getting difficult to troubleshoot because we are trying to anticipate every single scenario.

Another example: I would have to write a rule to see if the VP and Data Custodian are the same, another to see if the VP and the Supervisor are the same, and another to see if the Data Custodian and Supervisor are the same.  That's three rules just for one workflow.  That's insane.

[Jason Freeman]

And it's actually even more complex than that I stated above.

Let's say I try to create the following automation rule:

WHEN Approval Required

IF Item Matches JQL "HR Data Custodian" = "Immediate Supervisor"

THEN Auto-approve/decline

I can't do the above rule because it'll give the following error message: The value 'Immediate Supervisor' does not exist for the field 'HR Data Custodian'.  It forces me to choose the name of a user instead of a field name like "Immediate Supervisor."

So, this makes it substantially more complex.