How do we replicate custom fields from a parent issue to linked issues?

Question

Use case:

For all company approved initiatives, we insist that they go through a Joint Feasibility Analysis and Join Application Design session and the status of those sessions is indicated by 2 custom fields used in one of our Jira projects owned by PMO.

Issues in this board are cascaded down to appropriate teams taking action on the various bodies of work involved. We want to ensure that all new work being generated as part of these initiatives includes the appropriate status based on that of the parent as a means of improving visibility.

The goal is reducing the chance that something gets picked up which may not be entirely defined yet, having not gone through the design process.

Question:

Assuming that the same 2 fields exist for epic/story/task issue types, what is the best method for replicating these fields from parent to the linked issues?

Shawn LoPresto · Answer

Thanks Trudy. I will play around with that and see what I can do.

Bill, these processes are at the epic level on the epmo team, synced with another tool used for roadmap planning. As aop goals get pulled into quarterly planning each of the 16 different teams ends up building their own epics based on the work being required, with stories getting pulled into each sprint. These team epics are linked to the parent which tracks various criteria and status. Replicating these fields will save clicks into parents and gives the visibility of status , links to architecture diagrams etc.

Bill Sheboy · Answer

Hi @Shawn LoPresto

Yes, and...to what Trudy suggests...

At what scope/scale do the "Joint Feasibility Analysis and Join Application Design" occur: idea, epic, story, task, etc.?  If they occur only at the epic level, leading to the subsequent work break-down for the other issue types, why would those fields be needed on the child issues?

Thanks, and best regards,

Bill

Trudy P Claspill · Answer

I think I would use the Automation feature, triggering rules based on the fields being updated, and then using the Branch Condition to cascade the change to related issues.

I have not worked with really complex rules, so I don't know if you can effectively have multiple Branch Conditions to cascade the change through the entire hierarchy in one Rule. You might have to use multiple rules.