We are creating parent issues with subtasks. All our issues have: * A Start date * An Original estimate * A Due date Some of our issues are linked to other issues. I am looking for a solution which will make planning a lot easier. I want to use automation to achieve the following: * If an issue's start date is modified, it's Due date should be modified to a new date corresponding to the new start date + Original Estimate. * Linked issues (Blocked) with the status "To do" should also have their start and Due dates modified in the same fashion. * Linked issues (Blocked) with any status other than "To do" should have their Due date modified and their original estimate modified to the time between their Start date and the new Due Date. * Finally, if the trigger issue is a Subtask, the Parent's Due date should be modified to correspond with the Due date of the subtask with the latest Due date. (So this needs to find the due dates of the siblings and identify the latest date) I don't know if this can all be put into one automation rule.... but hopefully someone has an idea on how to fix this.

@Tijs Tijert @Tijs Tijert Hi Would you be able to provide me a screenshots of each of your rules for your "Update Start Date of dependent issues" automation? If you do I will then try to build these rules and test and then move from there. I don't see the "If: matches Linked issues present Types: blocks" as an option. I am a newbie to building these rules so I apologize in advance.

@Tijs Tijert Hi Would you be able to provide me a screenshots of each of your rules for your "Update Start Date of dependent issues" automation? If you do I will then try to build these rules and test and then move from there. I don't see the "If: matches linked issues present types: block" as an option. I am a newbie to building these rules so I apologize in advance.

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; } } }

Automation: The ultimate start- and due date modifier

Tijs Tijert

We are creating parent issues with subtasks.

All our issues have:

A Start date
An Original estimate
A Due date

Some of our issues are linked to other issues.

I am looking for a solution which will make planning a lot easier.
I want to use automation to achieve the following:

If an issue's start date is modified, it's Due date should be modified to a new date corresponding to the new start date + Original Estimate.
Linked issues (Blocked) with the status "To do" should also have their start and Due dates modified in the same fashion.
Linked issues (Blocked) with any status other than "To do" should have their Due date modified and their original estimate modified to the time between their Start date and the new Due Date.
Finally, if the trigger issue is a Subtask, the Parent's Due date should be modified to correspond with the Due date of the subtask with the latest Due date. (So this needs to find the due dates of the siblings and identify the latest date)

I don't know if this can all be put into one automation rule.... but hopefully someone has an idea on how to fix this.

Accepted answers

All comments

Mykenna Cepek_j7uztf

Jira Automation will likely be able to handle your use-cases. It will likely take at least two automation rules to accomplish what you want to do. Here are my thoughts and suggestions:

Your first bullet is a relatively easy rule. The funnest part will be performing the date computation, which automation fully supports. You can probably just use the data in the issue (rather than needing to access the FieldChange smart value) to compute the new End Date. I'd suggest working on this by itself first and get it to work as expected, to get a feel for the work ahead of you.
Your last bullet point might work best as an enhancement to the rule I outlined above. Use a conditional to check for the Issue Type, and if it is a Subtask, then continue on in the rule to branch into the parent Story and update that Due Date. The tricky part here is finding the "latest due date among that story's Subtasks". Please see more details on this under my "Note 1" below.
Your 2nd and 3rd bullets might be served best by a second rule that is triggered by the first rule. My thought here is that the first rule could be enhanced to loop through the linked issues, and set some field in those linked issues which triggers the second rule. The second rule would recompute the Due Date as needed. This two-level triggering is needed because you can't put a Loop inside a Loop with Automation today. Be sure to enable "allow other rule actions to trigger this rule" in the second rule, to enable this "chained trigger" behavior.

Note 1: Don't be tempted to loop through subtasks and set a variable to the "latest due date". You literally cannot do that in Jira Automation today. Instead, I'd suggest an approach that uses JQL which sorts (descending) the Subtasks under that Story by Due Date and grabs the first one. The Lookup Issues action and .last() function for list processing might be the way to go.

Bill Sheboy

Hi @Tijs Tijert

Yes, and...to add to what @Mykenna Cepek suggests:

Incrementally building this is key, as automation rules have no source control. Build one part to get it working and tested, and then copy that rule, disabling one of them, and continue work on the copy. Then you can revert if the rule gets too broken.
Given the details you have described, I believe you have a deadlock situation as all issues have those fields, you are changing some of them, and you are triggering changes on them. Consider writing down some specific examples to confirm if you do (or do not) have an impossible configuration to implement.

Kind regards,
Bill

Mykenna Cepek_j7uztf

I'm not sure I see the deadlock concern that Bill suggests, but it's wise to think through any re-triggering situation to ensure you don't create any kind of re-triggering loop between issues.

Bill's suggestion to build incrementally is spot-on!

A few more thoughts:

It sounds like your net goal is to have Due Date ultimately be fully computed. That's a pretty cool goal. However, if anyone manually modifies a Due Date, then some aspects of your rule might not function as intended. User training about which fields should be edited is recommended.
- If I was doing this, I'd add another rule to watch for manual changes to Due Date and send me a notification, so that I could know who needs "continuing education" on the new process. Beware doing this, though, if you are concerned about rule execution limitations, since this one will get triggered a lot.
You might consider excluding all "Done" issues (StatusCategory=Done) from all of these rules. Minimizing the time rules take is a good goal, and updating completed issues seems to have minimal value; but you should validate that.
I find it interesting that you're using "Original Estimate", rather than the Time Remaining value. It's not wrong, just confirming that you're purposely not using Time Remaining.

Bill Sheboy

Hi, Mykenna!

For the possible deadlock, I was noting the path of parents can change children...and children can change parent's dates. Which could lead to either rule looping or rules not firing when the engines "runaway" detector halts processing.

For the manual "tampering" scenario, we had a similar case when we used automation to measure cycle times. The fix was to check initiators and the changelog to "undo" the edit when it was not possible to recalculate the value.

Kind regards,
Bill

Tijs Tijert

I did try it out but never really got it to work.
It is something we might start puzzeling on again in the future but at the moment there are other pressing issues to attend to and improving jira efficiency is not one of them I'm afraid.... but if you give it a try and figure it out I'd be happy to use that knowledge as well!

Sven_g7sk34

Hi @Tijs Tijert

I stumbled upon your screenshots today as I'm working on a similar automation. Perhaps you've managed to make your automation run reliably in the meantime. From my perspective, the only thing missing is the step "re-fetch issue date" between adjusting the "Start date" and "Due date," as you're changing the start date first and then calculating with it in the next step. However, at that point, the automation still has the original start date in mind.

My modified automation works flawlessly, and the Epic aligns perfectly as well.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud

atl-gruland