Cloud automation when an epic is added to a ticket

[Remi Preghenella]

Hi,
I'm trying to automate the transition of a ticket when it is added to an epic using the following:

I've tried many options with the command "Field value changed" but none of them work. 
According to the documentation, I could also use a regular expression to match the field name that is changed but it doesn't let me validate my regex.

Any help would be greatly appreciated.

Thanks,
Rémi

[Mark Segall]

Hi @Remi Preghenella - You're on the right path with the Field Value Changed trigger.  Just make sure the field you're working with is one of these two depending upon the type of project you're working with:

• Epic Link field (Company Managed project)
• Parent field (Team Managed project)

[Remi Preghenella]

Hi @Mark Segall
Thank you for the reply.
As I use a Team Managed project, I've based the Field Value Changed trigger on Parent Link.
However, the rule is never triggered!

Using the API, I can see/confirm that the issue is updated and a parent is added.

The rule is super simple so I wouldn't expect any issues:

[Mark Segall]

Hi @Remi Preghenella - Team Managed projects will use Parent. Parent Link is something entirely different:

• Parent - Used for linking Sub-Tasks to Stories/Tasks/Bugs and for Team-Managed projects, Stories/Tasks to Epics
• Parent Link - This is specifically used by company managed projects that are utilizing Advanced Roadmaps to create a hierarchy of issues above the epic.

[Remi Preghenella]

I don't have the Parent option though in the list of fields.

Thx

[Mark Segall]

Learn something new every day.  ;-)

So, I did some digging and found that this is a limitation of Team Managed projects. However, I did find this reference:

https://community.atlassian.com/t5/Jira-Cloud-Admins-discussions/Automation-Rule-Triggered-by-Change-in-Parent/td-p/1724967

Although their use case is specific to sub-tasks, the workaround proposed should work for epics.  You would just need to replace the condition

• Issue Type = Sub-Task

with

• Issue Type is not one of Epic, Sub-Task

This will ensure the rule only cares about issues that link up to the epic.

From there, the use of that change log smart value should do the trick.

Note - As pointed out, because you're using Issue Updated, this is going to fire on every single update, so if your project is very active, you may want to keep an eye on the rule's audit log to make sure it is not in danger of getting throttled.

[Remi Preghenella]

Thank you for the workaround.
As I expect a lot of updates on this project, I won't implement the automation rule to avoid the rule threshold. I'll run an API call daily instead.

That said, it might be a good idea to add the Epic change trigger in the automation rules at some point ;)

[Mark Segall]

If this is for a single project, it doesn't hurt to set up the rule and let it go for a few days just to see how active it will be.  If you have the initial condition set right, it should be less than a second before it exits out.  You get like 3600 seconds per 12-hour block before a rule throttles out.