Automation rule trigger help

[Ann Rumenapp]

We use Jira premium, company-managed projects with a jira hierarchy as follows:

Level 4 = OKR (custom issue type)

Level 3 = Change Initiative (Custom issue type)

Level 2 = Epic or Change Event (custom issue type)

Level 1 = Feature or CCR (both are custom issue types)

Level 0 = All other standard issue types

All Sub-task Issue types

I need to write an automation rule to populate a field on issue create for issues that are children of the Change Event issue type and excludes children of the Epic issue type.  What automation rule trigger would you recommend for this?

[Trudy Claspill · Accepted solution]

Hello @Ann Rumenapp 

@Dick 's answer is not quite right.

You said you want to populate a field when the issue is created. So your trigger would be Issue Created.

You said you want this to modify only issues that are children of Change Requests. For that you need to add Conditions after the trigger.

One Condition you need is confirming that your trigger issue has a Parent at all.

Use the Related Issues condition and set it to Parent Exists

Next you said you want to have this affect only the children of Change Requests, not the children of Epics.

Add another Related Issues Condition, but this time choose JQL and set it thus:

This will confirm that the parent of the trigger issue is a Change Request.

[Dick]

You're right @Trudy Claspill , I mixed up the change initiative and change request. Where I mentioned epic, it should be change request... 

I'll change it, to keep things neat and to the point.

Dick

[Trudy Claspill]

Hello @Ann Rumenapp 

I did not want to use an issue create trigger because we don't have unlimited automation rule execution, and that will get expensive if every issue in the company triggers the rule.

Simply triggering a rule does not count against your Automation Rule usage. Rules count only when they perform one or more of a specified set of actions. You can trigger rules thousands of times and end up with a usage count in the hundreds if the majority of the rules don't end up doing any work. For more details on this refer to

How is my usage calculated? 

When the conditions added after the trigger don't pass and no actions end up being executed, the rule will not count against your usage.

In my example above:

1. If the triggering issue has no parent, the first condition fails. The rule stops running and doesn't count against your usage.

2. If the triggering issue has a parent, but the parent is not of type "Change Request", the second condition fails. The rule stops running and doesn't count against your usage.

[Dick · Accepted solution]

Hi @Ann Rumenapp 

You need to trigger on issue creation, then check if it's of the change request issuetype and check if it has a parent. If it does have a parent, you follow up by an edit action in which you fill the triggerissue's special field.

You should be aware that users might also set the parent link of a change request ticket after creation. In this case you would need an additional automation that is on field change of the parent field, then check if we're talking about a change request issuetype. Only if it's an change request, you need to check if the the parent field is filled or empty, followed by editing the special field of the trigger issue if its parent field is filled. 

Kind regards,

Dick

[Ann Rumenapp]

Parent field is required on creation of the change request, however it can be edited after creation therefore I was considering using multiple rules or a trigger of parent field value changing.

[Ann Rumenapp]

Thank you for the thoughts.  I did not want to use an issue create trigger because we don't have unlimited automation rule execution, and that will get expensive if every issue in the company triggers the rule.

I also don't want to update every issue created just specific ones based on the project configuration.  I know I can limit the rule scope for this part but was hoping for a different trigger option.