Automation: The ultimate start- and due date modifier

[Tijs Tijert]

We are creating parent issues with subtasks.

All our issues have:

1. A Start date
2. An Original estimate
3. 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.

[Sven]

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.

[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!

[Mykenna Cepek]

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:

1. 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.
2. 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.
3. 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]

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

[Mykenna Cepek]

Ah, I see your concern @Bill Sheboy.

I think the solution (to avoid looping/deadlock) is to be mindful of what fields are being used at triggers, and what fields are being changed. If...

• The first rule triggers (only) on a change to the "Start Date", and revises "Due Date" in other issues
• The second rule triggers on changes to "Due Date", and revises "Due Date" in other issues
• Then the second rule might inadvertently re-trigger itself

Then yes, that's probably not going to work out very well.

Triggering the second rule on yet another field might solve the problem (with a downside of having another exposed field).

Accomplishing the original goals will be non-trivial. @Tijs Tijert be sure to write an article here for the Community if/when you figure this all out. It would be a great contribution back.

Another thought: think through what should happen if someone changes the Original Estimate.

[Tijs Tijert]

I will take the advise from you both into consideration and hope I will have some time soon to try and find a working solution. Once I do I will post it here for sure.

[Jacqui Rayner]

@Tijs Tijert did you ever find a solution to your original question? 

[jeanne_higgins]

@Tijs Tijert did you build this Jira rule automation because I would be interested in it as well. If you can share it we can build it and test it as well and share?

[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!

[Jeanne Higgins]

@Tijs Tijert If you can provide screenshots of the rules, I could build them and do some testing.

[Tijs Tijert]

I have made some screenshots.
There are 2 automation rules that should do the deed.... but it is not completely reliable. Especially the rule that needs to update the due date of the parent.

I will post the screenshots of each rule in a separate reply below.

[Tijs Tijert]

Rule: Update Start Date of dependent issues

[Tijs Tijert]

Rule: Change Due date of parent to youngest due date of any child issue

[Jeanne Higgins]

@Tijs Tijert Thank you for the screenshots.  I will look at it, they may be different, but what I am looking for is functionality like MS Project which is MS Project today: When any task start date is updated, the tasks due date adjusted based on the task duration. If there are dependent tasks they adjust automatically based on duration for each task.  What also would be nice if ARM would do is when you put in the initial project start task like kick off call start date then all tasks' start and end dates are added based on their duration.

[Tijs Tijert]

Yes that is also exactly what I am looking to do... the kick-off meeting is a nice idea, but not really applicable to our organization

[Jeanne Higgins]

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

[Jeanne Higgins]

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