How would our team be able to have fields transfer information from an epic into a child issue. We track certain fields dealing with our project ID, requestors, assignee, and developers, however, it has been become a manual process that our team has to keep going back to epic to view certain field data.
I would want to know how when I enter information in the fields section in the EPIC, that information can transfer over to the fields in child issues.
Hi @Luis Dominguez ,
from how far I got your requirement I think this could be done with JIRA internal automation. Just would have to specify the use case more in detail:
Best
Stefan
This example of an automation rule will always be triggered when an EPIC issue is updated. If this condition is fullfilled all stories/issues in the epic will be edited and inherit (in this case the value of the field "Country") from the EPIC (see screenshot)
There might be some further refinement of the trigger or fields or conditions but maybe this is something you could start with to then better investigate your special requirements while testing the rule.
Looking forward to hearing from you.
Best
Stefan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Stefan,
Thank you let me try this out. The way we run projects is unique and it would be to mirror the child and parent status
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Luis Dominguez ,
Hope you are doing well!
With reference to the above logic which was really helpful to sort few of my issues, I also wanted to capture the parent epic status to a custom filed in my child item(should not be mirroring - means if child status changes it shouldn't trigger any changes to parent status). Only the current status I wanted to get captured in my child custom filed.
Regards
Rahul Jith
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Luis,
there are different options to tackle your problem:
1) Built In Jira Automation
As you are working on Jira Cloud, you could use built-in Automation for your purpose.
Example to Update Assignee on Epics children:
The result (for the Assignee field example should look like this:)
However, this rule might trigger quite often on your instance and there are significant limits on the Automation Rule executions per month in the different cloud plans.
(Currently: Free: 100 total Executions per month, Standard 500 total Executions per Month, Premium: 1000*#users per month.) Having an automation rule run so much might also affect performance.
This problem grows if you add an additional similar rule that updates changes from stories into the epic and propagates to all "sibling" stories again.
2) Leverage an app (e.g. Jira Workflow Toolbox)
The Alternative would be to leverage an App for this and trigger the updates (manually) with a post-function. For example with the App Jira Workflow Toolbox you can do the following.
If you add this post-function to the Create-Transition of your workflow as well, the story/task will also be initialized correctly from the beginning.
But if something changes in the Epic, someone needs to press the button "Fetch Info from Epic" to update the issue fields.
3) A Combination of this
An automation rule that runs once a night/week and executes this transition on all relevant issues could be a compromise between automation rule executions limit and necessary manual input.
Hope this helps,
Barbara
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Barbara Schwarzwald [Decadis AG] ,
awesome answer showing up so many ways that all lead to a quite good solution :)
I just wanted to add that the limit of rule executions is valid for global- and multi-project execution rules. There is no limit for executions for single-project rules.
Best
Stefan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
thank you Barbara and Stefan, Let me try Stefan's response first. The feature I am asking for is a ok to have but not something we need to invest lots of time and money in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Barbara Schwarzwald [Decadis AG] your solution works great, thank you very much. I will also have to keep an eye out if this will be too demanding on our jira.
However I was not able to use this same rule to update fields in sub-tasks.
Do you have any idea why this didnt work?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Maximilian Köhler
if you want to apply a similar rule, but on the level of subtasks, you need to use a different Branch type (namely "Sub-Tasks" instead of "Stories (or other Issues in Epic)".
If this is not the issue, can you show me a screen shot of your rule and a short "if - then" explanation of what you are trying to accomplish?
Best,
Barbara
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I did just that as you can see here
I tried doing the same but in the same rule as for the "Stories", made no difference. I am also wondering which issue I should copy for the sub-tasks, I think I have tried all variations but the sub-tasks never update when I change values in the Epic.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Maximilian Köhler ,
i think I have an idea, what could be the issue.
If I understand correctly, you have two rules. One rule as above, that updates the story from the epic and a second one that's supposed to copy from the story level to the sub-tasks below. The first one works, the second doesn't.
This is probably because (by default) rules don't trigger each other. This is to avoid infinite loops or performance issues in general.
You can skip this precaution in a specific rule under rule details and have it triggered by other rules:
Let me know if this solves your issue.
If your problem is instead, that some but not all issues are updated, make sure, that you did not accidently check "Only include issues that have changed since the last time this rule executed" in the Branch options:
Hope this helps,
Barbara
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Edit2: So once I unchecked "Only include issues that have changed since the last time this rule executed" for the subtask rule it works.
Edit: Now suddenly it doesn't work anymore, I have to do some more troubleshooting.
Hi @Barbara Schwarzwald [Decadis AG] I kept everything the same, except I did as you said and allowed the substask rule to be triggered by another rule. Also in the subtask rule I set the "Edit Issue" to "Copy FIELD from Trigger Issue", copying from any other Issue doesn't work.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Luis
For such a thing you might want to invest in a plugin such as scriptrunner or the excellent JWT.
How I would do it:
If you want to change other information (Assignee, developer, project id etc) you can add custom fields to this screen's transition and use similar behaviors.
This is just an idea, I am sure there are better solutions, however I am afraid none with Jira out of the box, you will most probably need a plugin to obtain the results you wish.
I hope this helps
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You can also try Field Mirror for Jira in Atlassian Marketplace if that helps. https://marketplace.atlassian.com/apps/1230885/field-mirror-for-jira-fmj?hosting=cloud&tab=overview
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.