When Issue transitioned for linked issue IF X then transition to Y, IF A then transition to B etc

[Eric Huang]

I'm a few hours new to Jira and starting to set up some automation of cloned issue statuses between different boards/projects.

If I transition issue A in Project 1, I want the cloned (is cloned by) issue in Project 2 to transition accordingly.

The below automation works well, except it means I need to create 3-4 additional automation rules which inadvertently chews through our automation limits; Is this an incorrect understanding about automation limits and counting?

What I would like to do is nestle all 3-4 transition scenarios as IF-THEN so all are under the same Rule, and I suppose would count as 1 automation?

I'm not sure how to do this as I have a "issue fields condition" set in each branch which doesn't work because it relates to the "is cloned by" issue, and not the original issue.  "When Issue Transition" conditions seem to control specific transition scenarios".

Is there a way to do this, or am I overcomplicating this and can continue to stick with 4 rules.

thank you!

[Trudy Claspill · Accepted solution]

Hello @Eric Huang 

Welcome to the Atlassian community.

One solution is to use a Smart Value condition instead of an Issue Field condition. With a smart value condition you can compare a value to the Status value of the issue that triggered the rule using

{{triggerIssue.status.name}}

[Eric Huang]

Hi Trudy, thank you for reviewing my question and for your response.  I must admit, I have zero understanding currently on how and when to use Smart Values.  So whilst I appreciate your proposal, I don't have a good understanding of how or where to apply it in my current logic.

... and whether I even need to solve this issue since it was initially driven by assuming multiple rules would impact my automation run limits.

[Trudy Claspill]

In this case having branches or having multiple rules would not make a significant difference in the impact to your automation rule run limits. You would be either triggering one rule to run for every transition or each transition would trigger one of several different rules. You can learn more about how usage is calculated here:

https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/

Smart values can be used when you are trying to access some element that does not have a simple/default access option. For instance, as you discovered, within a branch the actions you execute in the branch affect the issue that is "in focus" in that branch. The issue "in focus" can be access using the smart value {{issue}}. If your rule has no branches, then {{issue}} also refers to the rule that triggered the issue.

To get to information that is in the issue that triggered the rule, you can also always use {{triggerIssue}}, regardless of whether you are in a branch or not.

Many issue fields have different attributes to them. For instance a user identified in a User Picker field, like Assignee, has a name, and account ID, and an email. To get a single one of those attributes you can use a smart value like:

{{issue.assignee.email}}

There is a lot of documentation on smart values available here:

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

...including details on how to access different attributes of fields, and functions that you can use with smart values, such as getting the difference between two dates.

Most folks getting started with Automation start with trying to use just the default functionality, until they run into something that they can't figure out. Then they start diving into smart values.

When working on an Automation also take a look at the Templates tab. There are some sample automation rules there that might help you figure out how to construct what you want.

[Trudy Claspill]

Hello @Eric Huang 

With the response I provided were you able to address your requirement?

If so, please consider clicking on the Accept Answer button to mark you post as Solved.

If you still have questions about how to meet your requirement, please let us know.

[Eric Huang]

Thanks @Trudy Claspill appreciate your in depth explanation and help here; I've solved my needs based on your explanation about how automation counts are calculated and resolved that there is no need for the complexity of a specific automation to run across all scenarios.