Hello Atlassian Community,
I am looking for some guidance on managing task dependencies within Jira Work Management. Our company is currently on a standard plan and upgrading to a premium plan for Advanced Roadmaps is not feasible at the moment due to budget constraints.
Here's our scenario: We have two tasks, Task A and Task B. Task A blocks Task B, and we need to ensure that the completion date of Task A is always scheduled before the start date of Task B. We want this scheduling to be reflected in our project timeline automatically. We use Start and Due dates fields to control timelines.
The Challenge: We need a solution that would allow us to maintain this dependency rule within our timelines without manual intervention. Since we are not able to use Advanced Roadmaps, we are looking for alternative methods or best practices within the standard Jira Work Management capabilities.
What we’ve considered:
My Question: Is there a way within Jira Work Management (standard plan) to automatically adjust the start and due dates of dependent tasks to reflect the correct order of operations? If not, what are the recommended best practices to ensure that the dependent task (Task B) is always scheduled to start only after the preceding task (Task A) is completed?
We appreciate any advice, workarounds, or insights the community can provide.
Hi @Muhanned Shahada ,
This can be achieved using Automation rules. I've depicted an example below for when one issue is linked to another as a blocker.
Let's take a closer look at the individual steps.
1. The first step (trigger) is straightforward - when issue is linked and the link type is blocks
2. Then we create a variable with the value of this ticket's due date. Note that in this type of link, the issue that blocks the other one is the parent issue.
3. Then we create a "for each" component for all linked issues.
The "only include issues that have changed" can be selected in this case.
4. Here we have an if condition to ensure we only change the start date for issues for which this is less than or equal to the due date of the blocker
5. Finally, we set the start date of the issues that remain to one day after the due date of the blocker.
You may also need to create another rule where the trigger condition is a change in the Due Date of a ticket.
Hope that helps!
Hi @Hariharan Iyer
Thank you very much for this answer, it is helpful but the problem here it only works on parent issues, in my case the issues are not children to a parent issue, they are different user stories but dependant on each other. How would you advice to solve this?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Muhanned Shahada , this would work on any issues that have a blocked/is blocked by relation. The parent* name that I gave for the variable is just an example.
However, there is a restriction here that you have to link the issues with the "blocks" or "is blocked by" links. If that information is not stored in jira but somewhere else, then this automation would not work.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Hariharan Iyer
Thank you for your support, for some reason the automation isn't working for me. Here is a screen shot of the automation. Does fields letter case matter? in my case it is ( Start date) & ( Due date)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Would you mind sharing a screenshot of the logs, so we can debug this?
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.
Thanks. It looks like the tickets are not satisfying the if check. Maybe because:
1. the start date of blocked issue is not set, or
2. the due date of blocker is not set, or
2. start date of blocked issue is already set to a day after the blocker's due date (or later).
Can you check this once?
If it's the second or third, the rule is working as expected.
If it's the first, then we can either remove the if check or replace it with a JQL if check
{{issue.Start Date}} IS EMPTY OR {{issue.Start Date}} < {{parentDate.plusBusinessDays(1)}}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Hariharan Iyer
I did check the possible causes, Start and due date are all set.. I tried to change it to JQL condition but it was failing... Just to make sure i explained myself correct, here is how the roadmap look like, what i am hoping to achieve is when i move Task A ( Blocker) to a date after start date of Blocked, want Task B and C to adjust automatically.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
In that case, can you try removing the "IF" condition? BTW, from the audit logs, is the rest of the rule correct? ie, do you expect TR-5 to be modified if TR-6 is changed, and TR-4 to be changed if TR-5 is changed?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I tried to remove the IF condition and it still didn't work.. Correct, your assumption is what i am hoping to achieve.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I used this rule and it worked for me
1. The trigger is set to "when value changes for due date"
2. The new value for "Start Date" is set to {{triggerIssue.Due date.plusBusinessDays(1)}}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I am new here
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.