Automation Rule Triggered by Change in Parent

[Lenny Tabakman]

Hello admins,

I am wondering if anyone has been able to create an Automation Rule or JMWE Event-based action that runs when a sub-task is moved from one parent to another. I need this functionality because we have fields that are unique to every parent issue that need to stay updated on the sub-task issue as well. Therefore my desired automation would update those fields from the sub-task's new parent when the parent is changed.

Thank you in advance!

Lenny

[Darshan Mandhane]

A condition based check if "Parent Link" has been changed for each "Issue updated" would do the trick.

[Lenny Tabakman]

@Darshan Mandhane I can see that testing the automation with the trigger set to value changes to Parent Link does not work, so it is interesting that a condition checking for a change to Parent Link would work instead. I am not sure how to check for a change in a condition. Could you provide any tips for that?

[Darshan Mandhane]

@Lenny Tabakman - Please see the below response from @Mykenna Cepek
She has added a screenshot of the automation rule. That's what I was suggesting. 

[Mykenna Cepek]

Part of the problem is that "Parent Link", as offered in the "Field Value Changed" trigger, watches for Story/Epic links that change -- not the Story/Subtasks relationship.

[UPDATE: The above is INCORRECT; the "Parent Link" is not related to the Story/Epic relationship; further details in my later comment below].

It's confusing that Jira has two completely separate mechanisms to handle the "parent-child" relationship between issues. Another area where you can see this distinction reflected in Automation is in the Smart Values for issue.parent (to get the Story of a Subtask issue) versus issue.epic (to get the Epic of a Story issue).

The following test rule worked as a workaround. A downside is that the rule will trigger for every issue edit (important if you are on a plan with limited number of rule executions).

[Lenny Tabakman]

@Mykenna Cepek Thanks for the information. Actually when I was testing, the Parent Link field value change trigger did not work for Epic Links changing. I am looking for a solution which does not rely on the Issue Updated trigger so I suppose this is simply not possible. I do not want the automation rule to run every time an issue is edited.

[Mykenna Cepek]

Interesting. I went back to retest, and I did confirm that the "Field Value Changed" trigger for "Parent Link" does NOT fire when "re-parenting" a Sub-task or a Story.

I found existing bug JIRAAUTOSERVER-79 which hints that the "Parent Link" field relates to Jira Portfolio usage.

After researching elsewhere (here and here and here), I confirmed that "Parent Link" is used exclusively for the Epic-to-XXX relationship, where XXX is an Initiative, Theme, or other hierarchy level defined (above Epics) in Portfolio.

Thus, "Parent Link" will not be useful in Automation when trying to detect changes to Epic/Story or Story/Subtask relationships.
_ _ _ _ _ _ _

I found JRACLOUD-76041 and JSWCLOUD-21098 which both bemoan the lack of Automation trigger support (in NextGen/TMP projects) for changes related to Epic/Story relationships. Might be worth voting and commenting on one or both of those.

Consider also making a new feature request for this. I'm in agreement with you that Automation should have a way to trigger on changes to the Epic/Story relationship (as well as changes to the Story/Subtask relationship).
_ _ _ _ _ _ _

The workaround outlined earlier does accomplish your goal, but at the expense of a lot of rule executions. However, Jira Free and Standard plan users likely can't use this workaround, due to the 100 or 500 rule executions per month limitations for those plans.
_ _ _ _ _ _ _

It's not easy to find a complete list of Automation limitations, so here they are:

• Automation Service Limits (not a complete list!)
• Automation limits by Jira Plan (scroll down to "Automation" in the first column and click that hyperlink, which shows the screenshot below).

Note that Jira Premium and Enterprise limits should not have to worry about the workaround above impacting any automation limits.

[Lenny Tabakman]

Thanks for the detailed response @Mykenna Cepek . I will probably submit a feature request as I think this is really important to have in Jira. Also I am on a Premium plan but on my instance there are so many other automations and updates to issues (it is a large instance) that having an automation that is triggered by issue updated is scary as it will be going off literally all the time, and possibly impacting other automations in the queue.

[Mykenna Cepek]

Keep in mind that a rule can be scoped to just certain projects, which can drastically reduce the number of monthly executions in a large organization.

Remember too that you can monitor your automation usage on the main Automation admin page:

If your support ticket spawns an issue on jira.atlassian.com, please feel free post a link to it here. That way I can vote for it, and others who find this discussion can vote for it too.

Including a link to this thread (in your support ticket) will provide some background for the Atlassian agent.

Thanks, and best wishes!

[Lenny Tabakman]

I have submitted https://jira.atlassian.com/browse/JRACLOUD-76853

[Mykenna Cepek]

Be sure to vote for it!

[Lenny Tabakman]

There are changes upcoming to Epic and Parent relationships so maybe this will be fixed: https://developer.atlassian.com/cloud/jira/platform/deprecation-notice-hierarchy-levels/

[Mykenna Cepek]

That's interesting, and it's a first step towards dealing with the mess that is currently "issue relationships in the Jira issue hierarchy".

However, these updates to the Jira API are only the start. Since Automation is dependent on the REST API, these updates to the API have to occur first.

Then Automation has to be updated to expose the new relationship construct in Triggers and Conditions and Actions.

I guess we can cross our fingers that this next logical step is on the Atlassian Roadmap. But votes on JRACLOUD-76853 will certainly help to prod that along.

[Azfar Masut]

FYI, for those coming from server land, you may use the logic Mykenna provided, however, use the following value for the changelog instead

• {{changelog.Parent Issue.fromString}}
  DOES NOT EQUAL
  {{changelog.Parent Issue.toString}}

[Carlos Sanchez]

Thank you @Azfar Masut ! Your tweak worked perfectly.