Create Automation to copy fields to epic to child ticket

[Kevin Kashou]

I need to orchestrate an automation that duplicates specific attributes from an epic story to its child tickets, covering various ticket types, and vice versa. So, if there are any alterations to a child ticket, the epic story will be updated accordingly. What's the optimum strategy to establish this? For instance, the Epic ticket has a 'frontend requirements' attribute and I aim to transpose that attribute's value to a 'Frontend Story' child ticket that incorporates a 'summary' attribute. Also, if adjustments are made to the 'frontend story' child ticket, I want it to reflect on the epic ticket, specifically updating the 'frontend requirements' attribute.

[Bill Sheboy · Accepted solution]

Hi @Kevin Kashou 

Please explain the problem you are trying to solve.  That is, "why" do this field synchronization?  Knowing that will help the community to offer better suggestions.

Until we know that...

Copying a field from a parent to its child issues is a relatively easy scenario to implement with automation rules: https://www.atlassian.com/software/jira/guides/automation/overview#what-is-automation  Similarly, it is easy to sum, average, etc. a field value in child issues up to a parent issue.

However you describe making that update bi-directional, where a change to a child can update the parent (and then presumably also cascade back down to update the children).  This could potentially lead to serious rule looping errors.

When thinking about the data in Jira issues, there is often one source issue's value, at one point in the hierarchy.  For example, an Epic's description may describe the business problem being solved, and it would not make sense to copy that description into every child issue: they would potentially get out of sync and there are many update paths such that re-sync may not always be possible.

Knowing the problem you are trying to solve may reveal other solution approaches than bi-directional update of fields in the issue hierarchy.

Kind regards,
Bill

[Kevin Kashou]

@Bill Sheboy We are restructuring our agency's ticket setup process to include epics that encompass requirements from different disciplines, such as frontend and backend development. These epics are intended to house child tickets, detailing how each aspect of a feature, component, or template will be built. The content of the child tickets should also reflect in the main epic ticket to maintain information consistency. Once both frontend and backend components are finalized, the epic ticket is passed to a QA personnel for a comprehensive assessment. To avoid them having to delve into individual child tickets, all necessary details are incorporated into the parent epic ticket. As such, whenever there's an update in any issue field, be it within an epic or child ticket, all stakeholders are instantaneously updated to ensure everyone is aligned with the latest developments.

Does that make sense? Unless you see a better way to do this I am all open ears for best implementations.

[Bill Sheboy]

Thank you for that information.  The described solution approach sounds like a process, rather a tooling problem: there is a need to improve information management for validation testing, including low-level details, when multiple teams / skill disciplines are involved in delivery.

You noted "all stakeholders are instantaneously updated", but I do not believe that is possible with current internet technology using Jira Cloud.  There would be some delay time, from seconds to minutes in the best cases.

Automation rules could be used to try to sync the fields.  Please see what I described earlier, noting the possible problems of update delays / failures caused by bi-directional updates.

[Kevin Kashou]

@Bill Sheboy 

We are implementing a bidirectional approach to link children tickets directly to the corresponding developer working on the feature, with the comprehensive requirements contained within the epic. The epic will consolidate both Front End and Back End information, providing a one-stop solution for the QA team to review, rather than necessitating viewing multiple tickets.

[John Funk · Accepted solution]

Hi Kevin,

So what would be the triggering event that would cause the update to happen? 

[Kevin Kashou]

@John Funk We possess an epic which contains tabs for general information, front end, and backend. Depending on whether the contents or fields in the front end tab have been updated, the corresponding fields in the epic or the associated child ticket will also be updated and it will work the same way with backend child ticket too.

[John Funk]

Okay, sounds like a rule with a Field Value Changed trigger. Then chose the fields that would cause the rule to fire. 

Next, add a Condition for Field Value, chose Issue Type field and select Equals Epic. 

Next, add a Branch and select Children

Finally add an action for Edit Issues under the branch.

Select the fields to be updated.

Click the 3 dots beside each field and select Copy. 

Click the words Current Issue and in the popup box that opens, select Trigger Issue instead of Current Issue. 

[Kevin Kashou]

Is it necessary to create individual rules for each field to copy? Or is it feasible to configure rules that will apply to every field, copying from the epic to various child tickets?

[John Funk]

No, you can do all of the fields at one time. 

[Kevin Kashou]

@John Funk https://share.cleanshot.com/P5gQX4yc is this how you recommend it? 

IT seems to be working but only one way which is epic to the children. Is there a way to update this rule so that it works from the children to the epic?

[John Funk]

Yes! That looks good. Give it a try.

[Kevin Kashou]

@John Funk so I gave it a shot and I tried all the options edit field options https://share.cleanshot.com/01lfVDVx Am I missing something? 

If I am trying on the Frontend Story, to modify the parent (EPIC) and duplicate the fields from the current Frontend Story to the parent (EPIC).

[Kevin Kashou]

@John Funk l

It appears that applying the 'if' and 'else if' statements have successfully solved the problem as demonstrated in screenshot https://share.cleanshot.com/JTZvTh1d.  Please let me know if you approve of this solution, or if there are any concerns you have about it.

[John Funk]

I think that looks fine. Especially if it solves the problem and gives you what you want. 

[Kalyan Sattaluri]

hello @Kevin Kashou 

Seems like you have found a solution to your problem, if so, please consider accepting solutions of John or Bill or both so that future folks can benefit when they are researching similar issues.

[Kevin Kashou]

@Kalyan Sattaluri accepted both since they helped me in different ways.