nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

John Funk

Hi Kevin,

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

Bill Sheboy

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

All comments

John Funk

Hi Kevin,

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

Bill Sheboy

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...

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.

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.

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

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?

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.

Kalyan Sattaluri_iinm1n

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud