You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I would like to create jira automation rules, which help me displaying the true lenght of an epic. Therefore start date and due date of an epic shall be copied based on its associated stories:
1. Epic start date shall be copied from the story with the earliest start date (belonging to the respective epic).
2. Epic due date shall be copied from the story with the latest due date (belonging to the respective epic).
How can I create such automation rules?
Thanks in advance.
Hi Leah, welcome to the Community.
Disclaimer - I have not done this and only briefly played w/ difference between dates using Automation.
Here is what I'm thinking....
Here is a doc on date functions in Automation - calculating-the-difference-between-two-dates
Sorry that this is not an actual example and hopefully someone w/ handson experience happens along but in the meantime maybe it gives you some ideas to play with on your own.
For your desired outcome, Jack's suggestion works well when you know that the start date and due dates of the child issues (stories) are accurate.
One way to help would be to use another automation rule to set a story's start date when it transitions into an "in progress" status. Due Date seems like a target to me, so if you need an accurate measure of duration, consider setting a custom field in the Epic to LastStoryDoneDate, setting it with another rule when stories are completed.
Please note: if you decide to use multiple rules which could trigger others, select the option of Allow Rule Trigger in the details of the downstream rules. That allows one rule to trigger another.
I'm struggling with this as well: basically, I've discovered that I implemented this exactly as you wrote :) BUT there is one major problem -
I have 2 stories, and the earliest start date for example is Jan 18. This was copied to the Epic, and now the Epic will start on Jan 18. So far - great.
Now - I'm changing the start date of the story to Jan 20. This won't be copied to the Epic since the rule copies the date only if it is earlier than the existing date.
So now I have an Epic that starts on Jan 18 when no Story starts on Jan 18.
I'm stuck... Any thoughts?
the solution (and i think there is one) really depends on your ability to clearly construct your UC/scenario. Basically, can you construct a simply if-this-then-this-else-if this-then-this-else.... structure.
I am thinking you just need tighter conditions to test what if/else block you need to execute.
With that said, one thing I am always looking out for when constructing automation rules is building fragile rules that can (and consequently will) break. It is hard for me to say if this is the case here. I would really need to fully understand and try to build for myself. I generally like to draw these things out and step back from them and play "what-ifs" to test them out.
Thank you @Jack Brickey .
Basically the need is to set dates on the Epic that starts on the earliest Story Start Date, and end on the latest Story Due Date.
So I need the rule to run over all the Stories in the Epic and extract the correct dates, coping them to the Epic dates.
Can this be done?
Yes, once you have the parent issue you can do that with:
The example is noted on this documentation page:
Sorry, I missed the user story part of your request. One way to do this is to trigger and check one-and-only-one story when its dates change, compared to the parent epic. I do not know how to do this for checking all the sibling stories as there are limitations to automation rule, loop processing.
Here is how for the Start Date, with the important techniques that you need to use the custom field name in JSON advanced edit versus the user-friendly name.
The rule is similar for the Due Date, with the important techniques that you update with JSON advanced edit and use smart values that do not match the user-friendly ones. The capitialization of duedate is all lowercase.
Please let me know if you have questions about these rules.
Hi @Bill Sheboy ,
There is one problem with the implementation you suggested (I've been struggling with this for few days now):
I have 2 stories, and in this example, the earliest start date is Jan 18. This date was copied to the Epic, and now the Epic will start on Jan 18. So far - great.
Now - I'm changing the start date of the story to Jan 20. This date won't be copied to the Epic since the rule copies the date only if it is earlier than the existing date.
So now I have an Epic that starts on Jan 18 when no Story starts on Jan 18. The earliest story starts at Jan 20th.
One solution depends upon two assumptions:
If those are valid assumptions, you may remove the rules' conditions checking less than/greater than and just update the epic whenever a story's start or due date change. This does not handle entry errors, which may be fixed by immediately re-editing the story.
If these are not valid assumptions, please consider changing the dates in the epic directly.
Thank you @Bill Sheboy
Actually, the assumption of "The last story changed "wins" to update the epic", is wrong: the stories that should update the epic are the one that starts earliest and the one that ends latest.
Whenever there is a change in stories dates, the rule should run through all the stories and check what is the earliest start date and what is the latest end date. Only those values should be copied to the epic.
Thanks again for clarifying.
The challenge with your use case is iterating over all of the stories to find the earliest start date (or latest due date). Automation rule execution *within* a branch is non-deterministic, and so you cannot rely upon execution order or even use of temporary variables.
Until one or both of those are improved in the tool there may not be a solution.
Perhaps... you could update the epic in the loop and re-fetch it repeatedly. I am unclear how the rule engine will respond to updating the parent within the loop. On certainty is the rule will slow down dramatically. I'll try a test for this to see what happens.
After my testing, I got this to work by keeping all of the stories in synch for Start Date and Due Date, and so "last wins" helps. Thus when you need an earlier (or later) Start Date, you change one story and it updates everything.
If synchronizing the stories' date values does not match your use case I do not know how to solve this.
Here is what worked for me for Start Date sync. Please see the earlier post for details on advanced comparisons and edits.
@Bill Sheboy thank you so much for all your efforts!
I couldn't understand - why are we automatically changing the dates of the story?
The use case says that user is changing the story dates, and the epic dates should be changed accordingly. Epic length should be equal to all stories length.
I also got to a point that the branch changed my story instead of the epic, but this is wrong, and I can't pass it.
I reached out to Atlassian as I see that the community so far gets the same results as mine. I will update if Atlassian will have a solution for this.
I looked for a solution for the same UC, its required for our Gantt as well.
I expected to find some more common solution (because it is kind of familiar with status alignment logic), but didn't found.
Have you got some solution for you UC? Could you share what was progressed since last update?
There are quite a few different use cases requested in this thread from 2020. It is unlikely there is one solution which will solve all possible needs.
I suggest creating a new question which clearly describes your use case, what you have tried thus far to solve it, and include a link in your question back to this one. The added benefit of a new question is others will see the new question; only people following this older post will see it otherwise.
Thanks, and kind regards,
Thanks Bill for the suggestion. Our use case aligns exactly with Ayelet's "The use case says that user is changing the story dates, and the epic dates should be changed accordingly. Epic length should be equal to all stories length. " Which would include the earliest start date and the latest due date rolled up to the Epic.
Was hoping Atlassian had provided a solution via automation to Ayelet's use case so we could implement it as well per customer's request.
Thanks, for clarifying. Now that the Jira Cloud LookupIssues action supports all fields, you can do this with:
Please check your smart values to confirm the date field names match the ones in your instance, perhaps using this how-to article: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/