How do you update the status of a ticket when it is blocked using automation?

[Youri Wims-Rico]

In my project, I've created a task (Task A) that I then added a link to another task (Task B). I created an automation rule (pictured below) in hopes that when Task A is linked using "blocked by" Ticket B, then Task A is transitioned to a "Blocked" status. However, it is not working and the rule doesn't even run although my automation appears to be correct given according to the documentation, Task A would be the destination issue.

I've also tried updating the When statement to "All link types" and it doesn't work. However, when I've removed the JQL condition from the example listed below, kept the When statement as pictured, and then update Task A as "blocks" Task B the automation rule runs and Task A updated to "Blocked" status. Logically, this isn't what I would want. In this case, it'd make sense for Task B to be transitioned to "Blocked" status in this case.

Any assistance would be appreciated—the goal is to ensure that when a task is linked using "blocked by" that that ticket it then transitioned to "Blocked" status.

[Bill Sheboy]

Hi @Youri Wims-Rico -- Welcome to the Atlassian Community!

Please post an image of the audit log details showing the rule execution.  That may help to explain this symptom.

Until we see that...

Are the linked issues in the same Jira project?

What is the project type for the issue(s): company-managed or team-managed?  You may find that information either in the list of projects or at the bottom-left of the page expanding area.

Kind regards,
Bill

[Youri Wims-Rico]

Hey Bill, thanks for the quick reply. See image below.

> Are the linked issues in the same Jira project?

No, they're in two different projects.

> What is the project type for the issue(s): company-managed or team-managed?

team managed

---

[Trudy Claspill]

In this example how was the link set up?

YYTP-1 blocks YOP-1 

or

YOP-1 blocks YYTP-1

Something to note about using the Issues Linked trigger is that the "source" issue and the "destination" issue are based on how the link relates the two issues. It doesn't have anything to do with which issue you are viewing when you create the link to another issue. 

So, if you are in issue A and you create a link to issue B thus:

A is blocked by B

...it is the creation of the link in B that triggers the rule. B is trigger issue and A is {{destinationIssue}}

So, if you are in issue A and you create a link to issue B thus:

A blocks B

...that is the equivalent of B is blocked by A.

In that case it is the creation of the link in A that triggers the rule. A is trigger issue and B is {{destinationIssue}}

Each link type has an inward and outward description. When you see

A <outward description> B

...then A is the source issue and B is the destination issue. When you see

A <inward description> B

...then B is the source issue and A is the destination issue. And the rule is always triggered by the source issue regardless of which issue you are in when you actually create the link.

I have to work through that every time I try to explain it, so if it doesn't seem clear do let us know and we'll try to make it more clear.

[Bill Sheboy]

When you need to access / read issues in another project, your rule needs to have multiple-project (or global) scope.  That is why the branch did not find the other issue.  To change the scope, your Jira Site Admin will need to help as that can only be changed from global rule settings.

Next, the status values in different Team-managed projects are unique.  If the status names are identical, I believe the transition will work.  If not, the status id must be used.

[Youri Wims-Rico]

Thank you both! Given the rule wasn't global, it only ran only tickets created in the project the rule was created in. I tested again and removed the IF condition and it now works as expected for rules in that project.

Really appreciate your assistance and will continue to look into global rules for more broad automation adoption.