Automation Rule

[Casey Enderlein]

Hi there - we want to configure an automation rule that automatically populates a custom field for child issues in Jira based on the parent issue setup. 

Desired outcome: If child issue is created and parent issue custom field 'intake category' = 'OP', then edit child issue's custom field 'intake category' to = 'OP'. 

Can you help guide me with the correct configuration to achieve this automation rule?

Thank you kindly

[Bill Sheboy]

Hi @Casey Enderlein 

You may actually want multiple rules for a scenario to copy a field from the parent to a child issue.  For example:

1. When a child issue is created, and has a parent with the field set, copy the field to the child issue
2. When a child issue edits its parent, and has a new parent with the field set, copy the field to the child issue
3. When someone manually edits a child issue and changes the custom field, then do ??? For example, perhaps set the field back to the parent value.
4. When the parent issue edits the custom field, then do ??? For example, perhaps copy the value to any child issues.
5. etc.

I encourage you to clarify which scenarios you want to address, and then try to create the first rule and test it.  Successfully using rules requires learning and experimentation.  If you run into challenges, please post an image of your complete rule and audit log details to provide context for the community to offer suggestions.

To get you started on creating your rule, please refer to these documentation and example sources:

• https://www.atlassian.com/software/jira/guides/automation/overview#what-is-automation
• https://www.atlassian.com/software/jira/automation-template-library#/rule-list?systemLabelId=all&page=1&pageSize=20&sortKey=name&sortOrder=ASC
• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/

Kind regards,
Bill

[Casey Enderlein]

Thanks, Bill. We want to start with scenario 1 (and then future state iterate upon setup with scenarios 2/3). Here is a screenshot of the rule configuration to attempt at achieving scenario 1; the audit log shows no actions performed when I ran a test (In the test I first created an Epic issue type with the defined intake category > then create a child issue for this epic and the intake category field was not edited to OP).

[Bill Sheboy]

Thanks for that information, Casey!

When using the Issue Created trigger, I recommend always adding the Re-fetch Issue action immediately after the trigger.  That trigger may fire so quickly that some data may not be available to the rule yet, causing the rule to not work as expected.  Please add that action and re-test your rule.

Also, please expand your audit log details with the "Show more" option and re-post the image.  That will show the specifics of what happened in the rule steps.

[Casey Enderlein]

Thanks for the quick reply, Bill. I made the suggested edit (screenshot of updated rule here)

Rule Setup

                               

I created a new child issue and the audit log says successful (screenshot below), however the child issue's field of intake category did not get edited to 'OP' as we desire (see screenshot below of the child issue and the parent issue)

Audit Log

   

Parent Issue

Child Issue

Perhaps instead of the rule setup 'editing' intake category for child issue to 'OP' upon creation - is there a way I can achieve just automatically populating this field based on parent issues selection?

[Casey Enderlein]

Hi there! Just checking in 

[Bill Sheboy]

Hi, Casey.  Have you tried using the "Copy from parent" option for the field in the edit action?

[Casey Enderlein]

thanks for getting back to me! Yes I tried this and still not yielding the result -- here are screenshots of the rule setup, audit log, and the issue of most recent test (TesHRIS-150 is the Parent; TesHRIS-153 is Child issue). Based on the audit log is this a branching issue? Should I just remove the branch all together/this is not needed since the edit functions specifies copy issue from parent?

[Bill Sheboy]

Yes, that is correct: remove the branch to make the rule look like this:

• trigger: issue created
• action: re-fetch issue
• action: edit issue, copying Intake Category from parent issue.

But based on your original question, do you only want to do this when the parent's value is "OP" or copy whatever is in the parent?

[Casey Enderlein]

Awesome, removing branch worked! Thank you, Bill. Copy whatever the parent is (pardon any confusion, I was focused on specific example that was occurring, but we want this to be consistent across parent/child setup).

[Casey Enderlein]

In running an additional test I am noticing this rule not working for all scenarios. The first test passed: I created a child issue and upon creation left 'intake category' custom field blank > when I finished creating child issue and refreshed page, it automatically edited 'intake category' field on child issue to match the parent selection of "OP".

Second test I ran failed with errors (audit log screenshot below): I created a child issue and incorrectly selected an option for custom field 'intake category'; I selected "Critical Ops/Core Services" for the child and parent has selection of "OP". I finished creating the child issue (refreshed page) and the intake category field did not override to copy the parent's selection of "OP", we still see the seleciton of "Critical Ops/core services", and received an automation email error.

Is this expected behavior for rule to only work if the custom field on child issue is left blank upon creation?

[Bill Sheboy]

Did the new issue TESHRIS-155 have a both a parent assigned and value in the parent's field at the time the rule triggered?

Are the parent and child issues both in the same project: TESHRIS?

[Casey Enderlein]

Apologies, it looks like I did not select the parent when creating that test for issue TESHRIS-155. In re-running same scenario (created new child issue with accurate parent issue) this worked successfully and the intake category on child issue was changed via the automation from critical ops/core services to OP.

I did a third scenario with TESHRIS-155 and on this already created issue (with intake category option selected as critical ops/core services) I chose to 'add a parent' - after adding the parent I can see the intake category for child issue TESHRIS-155 did not change via the automation to match parent. Is this expected since the rule is built on 'when issue created'?

[Bill Sheboy]

I am glad to learn that worked, and...

Yes, that is the expected behavior for setting the parent later.  Please see my original response as there are several cases to consider.  The Issue Created trigger will only handle the first one:

1. When a child issue is created, and has a parent with the field set, copy the field to the child issue

To handle adding / changing a parent issue for an existing issue, another rule would use the trigger on a change the the parent field.

[Casey Enderlein]

makes sense, thanks for confirming. As an admin I am noticing one thing, when an issue is created and there is no parent I receive an automation rule error. We understand not all issues will have a parent therefore don't want this to flag as an error... how can I adjust the rule to ensure this is not flagged as an error? Screenshot below of the error

[Bill Sheboy]

What do you want to do if there is no parent issue?

For example, if there are no changes to that field, you may add a condition to prevent further processing:

• trigger: issue created
• action: re-fetch issue
• smart value condition: 
  • first value: {{triggerIssue.parent}}
  • condition: does not equal
  • second value: leave this empty
• action: edit issue, copying Intake Category from parent issue.

[Casey Enderlein]

Thanks, Bill. If no parent issue we do not want the rule to trigger, so if an issue is created with no parent, then rule does not apply and reporter can proceed to create issue with whatever intake category they select. To confirm, what you've recommended will achieve this?

[Bill Sheboy]

Yes: as I described it, the rule will trigger and perform no actions when the condition is not met on the parent field.

[Casey Enderlein]

thanks, Bill! Testing was successful and no longer receiving error message as the rule condition is met. Appreciate all of your partnership and quick responses during this!