Specific Approvals Workflow Help

[Keratoconic]

Hello Atlassian Community,

I have a very specific workflow I'd like to try and get up and running.

When a new issue is created and if the approval field is not empty then move the issue to waiting for support, but only do this if the reporter is different than the approver (we don't want users auto approving their own requests)

If approver = reporter than we'd want the automation to mention the user in a comment letting them know that this request requires for them to enter their managers username on the request (approver) 

Then reject this request if this last condition meets.

Hopefully this makes sense

[Keratoconic]

.

[Trudy Claspill]

What is happening to an issue when it is rejected? Is that another type of status change?

TRIGGER: Issue Created
CONDITION: Issue Fields Condition
  Field: Approval
  Condition: is not equal to
  Value: EMPTY

CONDITION: If/Else 
  IF: Advanced Compare
    First value: {{triggerIssue.reporter}}
    Condition: equals
    Second value: {{triggerIssue.approval}}

    ACTION: Comment Issue

    ACTION: (the action need to indicate the request is rejected)

  ELSE:
    ACTION: Transition Issue
      Destination Status: waiting for support

[Keratoconic]

Hello @Trudy Claspill - Yes, when rejected it would move to a new status called cancelled (with a resolution)

[Trudy Claspill]

Then in the above rule where I put

ACTION: (the action need to indicate the request is rejected)

...you would use the Transition Issue action to transition the issue to cancelled and set the Resolution in the same step.

[Keratoconic]

This didn't work for some reason, I want to clarify that on the initial step it should move them to waiting for approval, not waiting for support. I have made that change though but it's still sending it straight to waiting for approval, it might not be reading the {triggerIssue.reporter}} and {{triggerIssue.approval}} correctly?

[Trudy Claspill]

Please show us the details of your automation rule.

Where I used {{triggerIssue.approval}} I meant to use approver. However, in that spot you need to substitute the actual name of the field that you use to document the approver.

[Keratoconic]

[Keratoconic]

The approver gets documented in the issue under the Jira native approvals activity

[Keratoconic]

This one worked {{issue.Approvers.displayName}} - is there way to actually tag the user within the comment so they get a notification via assist?

[Trudy Claspill]

The method to mention the issue Reporter in a comment added in an Automation Rule is described in the answer on this post:

https://community.atlassian.com/t5/Jira-Service-Management/How-to-include-reporter-within-a-comment-inserted-by-an/qaq-p/1975162

[Keratoconic]

Yeah I tried that, didn't work unfortunately, it just does not mention them.

[Trudy Claspill]

Please show us the details of your current automation rule and the comment created in an issue where the rule executed.

From the image you provided the smart value you used in the comment was {{triggerIssue.reporter}}

That does not match what is shown in the post I referenced. Using the guidance from that post you need to use the following to mention a user in a comment.

[~accountid:{{triggerIssue.reporter.accountId}}]

[Keratoconic]

Than you, I will make the change once again and test.

We just came across another blocker for this and it's that sometimes managers will create an issue on behalf of other users so sometimes the manager will most likely equal to the reporter but this use case should only be acceptable if there are more users on the request participants options (aside from the reporter/manager himself)

Not sure if this makes sense but trying to think how to get this logic added as well, sorry for the back and forth, you've helped a ton so far!

[Trudy Claspill]

Hello @Keratoconic 

You said more users in the "request participants" option. That is an option in Jira Service Management. Are you working with a Jira Service Management project?

Assuming you do, in fact, mean the Request Participants field, you should be able to add more conditions to your IF block to check the count of people listed in the Request Participants field, and to check if the reporter/manager is in that list. If the count of people is 1 and the reporter/assignee is the Request Participant, then you reject the issue. The smart value to check the count of users in the Request Participants field would be {{triggerIssue.Request participants.size}}

You may also want to have an Else-IF block in your rule to check if the Reporter = Approvers and the Request participants = 0. I assume you would want to reject the issue in that case also.

And the final Else would be reached when the Reporter is not the Approver and there are 2 or more Request Participants OR there is 1 Request Participant that is not the Reporter/Approver.

I have not thoroughly tested that out, so you should test it to ensure it works the way you want.