Creating Automation Rule to synchronize fields between issue and sub-task
Asked by mnd:

I am attempting to create a single Automation Rule that will allow me to keep several fields in-sync between an issue (where they can be set), and a sub-task (where they should inherit from the parent).

The challenge is that I need to do this both for when the sub-task is created (to initially set the fields from the parent), and also when the issue is updated (to keep the fields in-sync).

The fields being kept in-sync are a combination of default and custom fields.

I've tried creating a trigger for when an issue is created, and updated. Then I split the logic chain "For Sub-tasks" and "For Current Issue", depending on what is happening, a sub-task being created, or the issue being updated. Unfortunately I can't get both situations to work.

I've also tried a trigger for watching when specific fields are updated during a create and update event. Again, I can't seem to get all situations to work under a single rule.

Any suggestions on how to keep default and custom fields in-sync between an issue and it's sub-task, both when the issue is updated, and when the sub-task is created.

Thank you.

-----------

Edit 1 - adding more information

-----------

I'll try to explain it more thoroughly below.

I'm demonstrating the behavior in two automation rules - but hoping there is a better way, which combines them into a single rule.

In this project there is a sub-task called "Release Notes". There is also a custom field called "Primary QA" that exists on both the Release Note sub-task, and the parent issue. I would like to make sure that the "Primary QA" value of the parent is always in-sync with the "Primary QA" field in the "Release Notes" sub-task. These are the two scenarios I'm trying to make work.

1. When the "Primary QA" field is changed in the parent issue, the change is reflected in any existing "Release Notes" sub-tasks. (Currently working with the "Field Sync: Primary QA" automation rule below)
2. When a "Release Note" sub-task is created for the parent issue, the new sub-task's "Primary QA" matches what is in the parent issue. (Currently working in "Field Sync: Primary QA 2" automation rule. Attempted as the second branch chain in "Field Sync: Primary QA" automation rule).

It seems I can trigger on when a field is changed, or an issue is created, but if I could trigger on both states, then it seems like I could work through the logic in the automation rule.

Any suggestions would be appreciated. Thanks for your time!

![Field Sync - Primary QA 1.png](https://community.atlassian.com/t5/image/serverpage/image-id/118321i396F33FCAE1184B4/image-dimensions/223x605?v=v2 "Field Sync - Primary QA 1.png")![Field Sync - Primary QA 2.png](https://community.atlassian.com/t5/image/serverpage/image-id/118320iBADC15708383B0D4/image-dimensions/246x381?v=v2 "Field Sync - Primary QA 2.png")


Answers:
author: Hana Ku?erov?
body: Hi [@mnd](/t5/user/viewprofilepage/user-id/538133) ,

sorry for the late response, I needed to think about it a little bit.

It makes perfect sense to me to have two separate rules. Each of it will be triggered in different situation and for you as an administrator will be much easier to take care of these straightforward rules then merge them together.

I wanted to share you my automations screenshots, but you know what? Mine are in fact the same as yours. I think most people will think about this situation similarly and your setup is something which I would expect to find :-).

comments: author: mnd
body: [@Hana Ku?erov?](/t5/user/viewprofilepage/user-id/1226304) thanks for the response - I was hoping there would be a way for automation rules to allow two triggers, but I guess not. Thanks for your time.


Tags: jira-software