Automation - If 2 fields on 2 unlinked issues match then...

[Eli Cady]

Hello Everyone,

I am looking to create an automation to check if an Assignee is assigned to multiple issues that are not linked and both issues have a Status of "Working" to move the status of the issue that has been in the working status the longest to another status called "Work Paused"

I would use this automation to trigger another automation for time tracking and improve accuracy and ease of use. 

Any input is appreciated. 

[Trudy Claspill · Accepted solution]

Hello @Eli Cady 

Welcome to the Atlassian community.

Have you started to construct this rule? Can you show us what you have so far, and point out at what point your are struggling to figure out the next step?

When do you want this rule to run? Do you want it to run on a schedule, or in response to some issue activity (like an issue status being changed to Working)?

[Eli Cady]

Thank you @Trudy Claspill! Glad to be here.

I have not begun constructing the rule. I want this to work in response to a triggered activity.

example scenario:

Current status=

issue 1 assigned to Tech1

issue 2 assigned to Tech1

Issue 1 in working status

Issue 2 in assigned status

Triggering event=

Issue 2 gets moved to working status. 

Automation result of triggered event=

Issue 1 gets moved to Work Paused status immediately (or as close to immediate)

End result=

issue 1 assigned to Tech1

issue 2 assigned to Tech1

Issue 1 in work paused status

Issue 2 in working status

*For this example I used "Tech1" but would like this to apply for all techs in the environment that would enter this scenario

[Eli Cady]

This is what I have

[Trudy Claspill]

Thank you for the additional information.

So, the next step is to find out if there are other issues assigned to the same person that are already in the Working status, and if there are, change their status to Work Paused.

I would suggest the FOR EACH: Add a branch option. When you select that you get these options:

Select Branch rule / related issues. Then you get this:

In the Type of related issues pull down select JQL. You can then formulate a JQL statement to look for any other issues assigned to the same person as the triggering issue, that are also in the Working status. (I'm using In Progress as the status in my example.) Make sure that you uncheck the box pointed at by the red arrow.

The full JQL in my example is

issue != {{issue.key}} and assignee={{issue.assignee}} and status="In Progress"

You can reference information from the issues in the rule using smart values.

https://support.atlassian.com/cloud-automation/docs/smart-values-in-jira-automation/

In this JQL I'm asking for any issue that is not the trigger issue and is assigned to the same Assignee as the trigger issue and is in the status "In Progress" If there are any such issues, they've been in that status longer than the trigger issue, because the trigger issue was just changed to that status.

Note that this rule will be limited to looking for those issues only in the same project as the trigger issue.

Then, within the branch, you add the Transition Issue action to transition those issues you found to Work Paused. (In my example I'm using "To Do".)

[Wojciech Wardaszko]

Hi @Eli Cady
Welcome to the community!
@Trudy Claspill, your automation rule is nice, but I'm concerned that your rule would also affect the issue that triggered the rule.
To make the necessary exception, I'd recommend adjusting the JQL. Instead of the part "Issue != {{issue.key}}" - this is never true, so it filters out everything -  we could use key !={{triggerissue.key}} so we're sure we won't transition the trigger issue.
The assignee filter should say assignee = {{triggerissue.assignee}}

The JQL would look like this:

key != {{triggerissue.key}} and assignee = {{triggerissue.assignee}} and status = "In Progress"

With these adjustments, this solution should work pretty nicely. Of course, the transition should be to Work Paused and not "To Do", but that's for @Eli Cady  to set up.

Cheers!

[Bill Sheboy]

Hi @Wojciech Wardaszko 

In the rule Trudy suggested, the clause of issue != {{issue.key}} is in the branch's JQL, and so will work as expected.

At that point in the rule, {{issue}} and {{triggerIssue}} refer to the same thing, and so the branch will work to exclude the trigger issue.  Context is important for automation rules. The meaning of "current issue" and {{issue}} can change at different points, which is what allows branch references inside the branch to work.

Kind regards,
Bill

[Eli Cady]

I can verify what everyone said here is accurate. Both solutions were tested and work as intended. 

Thank you for the assistance and learning opportunity!