Automation: Copy latest "due date" value from stories to epic

[Leah Barthelme]

Hi everyone,

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.

[Jack Brickey · Accepted solution]

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

• Trigger - date field changed
• condition - issuetype = story or whatever are your types under the epic
• condition - something to ensure you only execute as needed and not on something you don't want to happen
• action - if/else block
  • if the associated epic has the date field empty then copy date from triggering issue
  • else use Compare two dates comparing date of trigger issue w/ epic if trigger is greater then copy into epic else exit

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.

[Bill Sheboy]

Hi @Leah Barthelme and @Jack Brickey 

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.

Best regards,

Bill

[Ayelet Ben-Tzur]

Hi @Jack Brickey 

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? 

[Jack Brickey]

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.

[Ayelet Ben-Tzur]

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?

[Isabel Gomes]

thank you @Ayelet Ben-Tzur, I have the same need!

is there a command for stories, similar to this one for subtasks:

{{issue.subtasks.duedate.max}}

?

[Bill Sheboy]

Hi @Isabel Gomes 

Yes, once you have the parent issue you can do that with:

{{issue.subtasks.Due date.max}}

The example is noted on this documentation page:

https://support.atlassian.com/jira-software-cloud/docs/smart-values-lists/

Best regards,

Bill

[Isabel Gomes]

I believe you're missing the point, @Bill Sheboy ...

We want to update epic according to story dates - not subtasks.

Is there a similar command?

[Bill Sheboy]

Hi @Isabel Gomes   

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.

• Trigger: field change for Start Date
• Advanced Compare Condition: {{issue.Start Date}} does not equal empty
• Related Issues Condition: epic exists
• Branch: on the epic (parent)
  • Advanced Compare Condition:  which can handle the Epic dates being blank initially by using a large default number, 99999999
    • {{triggerIssue.Start Date}}
    • is less than
    • {{issue.Start Date|99999999}}
  • Action: edit issue, advanced with JSON, using the custom field name for Start Date

{
    "fields": {
        "customfield_10910": "{{triggerIssue.customfield_10910}}"
    }
}

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.

• Trigger: field change for Due Date
• Advanced Compare Condition: {{issue.duedate}} does not equal empty
• Related Issues Condition: epic exists
• Branch: on the epic (parent)
  • Advanced Compare Condition:  which can handle the Epic dates being blank initially by using 0 for the date
    • {{triggerIssue.duedate}}
    • is greater than
    • {{issue.duedate|0}}
  • Action: edit issue, advanced with JSON, using the custom field name for Start Date

{
    "fields": {
        "duedate": "{{triggerIssue.duedate}}"
    }
}

Please let me know if you have questions about these rules.

[Ayelet Ben-Tzur]

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.

Any ideas?

[Bill Sheboy]

Hi @Ayelet Ben-Tzur 

One solution depends upon two assumptions:

• The child stories of an epic may have different start and due dates
• The last story changed "wins" to update the epic

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.

[Ayelet Ben-Tzur]

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.

[Bill Sheboy]

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.

[Bill Sheboy]

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.

• Trigger: when Start Date changes
• Advanced compare Start Date is not empty
• Related Issues Condition: epic exists
• Branch on JQL: "Epic Link" = {{issue.Epic Link}} AND statusCategory IN ("To Do", "In Progress")
  • Advanced compare: {{issue.Start Date}} does not equal {{triggerIssue.Start Date}}
  • Action: edit issue, advanced with JSON, using the custom field name for Start Date
• Branch on Epic parent
  • Advanced compare: {{issue.Start Date}} does not equal {{triggerIssue.Start Date}}
  • Action: edit issue, advanced with JSON, using the custom field name for Start Date

[Ayelet Ben-Tzur]

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

Thank you!

Ayelet 

[Omer Agami]

Hi @Ayelet Ben-Tzur 

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?

[Kelsey McDowell]

Hi @Ayelet Ben-Tzur ,

Can you please share if Atlassian has a solution for this functionality via automation? 

[Bill Sheboy]

Hi @Kelsey McDowell 

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,
Bill

[Kelsey McDowell]

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.

[Bill Sheboy]

Thanks, for clarifying.  Now that the Jira Cloud LookupIssues action supports all fields, you can do this with:

• trigger: on start date or due date change (or use issue updated trigger and conditions to check which field changed)
• condition: the issue is a story
• condition: the issue has an epic parent
• action: lookup issues with JQL to gather all siblings with the same parent epic
• branch: to the epic parent
  • action: edit the issue to set the fields...
    • start date to {{lookupIssues.Start date.min}}
    • due date to {{lookupIssues.dueDate.max}}

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/

[Devanshi]

Hey! can you please provide this in automation playground :)

Thank you

[Marlene Kegel - codefortynine]

Welcome, @Leah Barthelme !

Depending on how you configured your custom fields, your use case should be possible with our Jira cloud app Dynamic Fields for Jira.

If you need help in creating the custom expression for your dynamic field, please get in touch with us. We're always happy to help.