Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Automation Role: Copy custom field value to children when value changed on parent

Eszter Somossy
Contributor
February 25, 2024

Hi,

I ask for help concerning with creating /correcting an automation role.

@John Funk  could you, or anyone else, please help me? I would appreciate for any help.

The automation role should wor as followings:

  1. When custom field value changed on the parent (epic, story, task, bug)
  2. Copy custom field value to all child (standard issue types and sub-tasks).

I have managed to set the automation for story, task and bug issue types,

but I am struggling to manage this role for sub-tasks.

I created one automation role, that works as my acceptance criteria (when custom field value changed on parent, copies the custom field value for stories, tasks, bugs)

1. this is the first section of my role: automation-works-for -stories-tasks-bugs.png

2. But the 2. part of my automation role does not work:

automation-fails-for-sub-tasks.png

Here I attach a full screen just to let you see the whole process of my automation role:

automation-fails-for-sub-tasks-full-screen.png

I would appreciate any help to fix the role.

Thank you,

Eszter Somossy

 

 

 

1 answer

3 votes
John Funk
Community Champion
February 25, 2024

Hi Eszter,

If you are wanting to copy fields down from Epic to children and then from the children down to the sub-tasks, you will need two rules. This is because the branches will fire at the same time and not in sequential order. 

So I would do the first part of the rule that you have and delete the second Branch. Also add a Condition right after the trigger and before the branch to for Issue Type = Epic. 

Then copy that rule and rename it. And replace Issue Type = Epic with Issue Type not one of Epic, Sub-task (include any other issue type that you don't want to include who may have children). 

Be sure to check the box of the second rule in the rule details to allow it to be triggered by other rules. 

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 25, 2024

Hi @Eszter Somossy 

Adding to John's answer:

I do not believe any of the Re-fetch Issue actions are needed in your rules and so you may remove them to speed up processing (after you split the rules as John described).

Branches which could be on more-than-one-thing are run in parallel and asynchronously, and there is no guarantee when the branch will complete...up to the last step of the rule.  And so having a re-fetch only slows things down and will have no impact for this rule scenario as nothing from the edits will impact other issues.

Kind regards,
Bill

Eszter Somossy
Contributor
March 3, 2024

Hi @John Funk and @bill ,

Thank you for your answers.

I made the changes you suggested and it works for epic to children :)

The role runs smoothly from epic to story, but from there it doesn't go from story to sub-task. So if I change the value of the field in epic, it will be changed in story, but not in sub-task. On sub-task, the field value is only changed if I make the change on the story. So the rule does not "continue". Something is missing in the rule about story to sub-task, I 'm afraid.

2024-03-03 13_46_12-Rule builder - Automation - Jira.png

Kind regards,

Eszter

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 3, 2024

It is often better to have two (or more) separate rules for this scenario:

  1. Detect field change, condition confirms the issue type is an epic, and then branch to the child issues (e.g., Story, Task, Bug) to copy the field
  2. Detect field change, condition confirms the issue type is a Story, Task, or Bug, and then branch to the Subtasks to copy the field.  For this rule, the option to "Allow Rule Trigger" must be enabled, allowing the actions of the first rule to trigger this one.

It is possible to do this in one rule, by gathering all of the keys together first, using Lookup Issues and an advanced branch.  Although that rule can be more difficult to explain to others for maintenance.

 

Another challenge with the scenario of field synchronization is deciding how to handle all possible changes.  Please discuss these additional cases with your team to decide if they are worth addressing, as they may require additional rules.

  • What should be done if someone manually changes the fields in a subtask?
  • What should be done if someone manually changes the fields in a Story, Task, or Bug which has an Epic parent?
  • What should be done if a subtask moves to a different parent?
  • What should be done if a Story, Task, or Bug moves to a different Epic parent?
  • Should any issues which are already completed be updated?
  • What should be done if an Epic with child issues is deleted?

 

Like John Funk likes this

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events