How to create automation for interconnected items on the timeline with dependencies (blockers)?
Asked by Hernani J?nior:

Hello, everyone!

I'm trying to set up an automation in Jira so that when the start or completion date of a blocking task is changed, the date of the blocked task is automatically adjusted. Can anyone share a step-by-step guide on how to do this?

If there is any official documentation or practical examples that could help me, that would be great!

Thank you in advance for any guidance!


Answers:
author: Trudy Claspill
body: Hello [@Hernani J?nior](/t5/user/viewprofilepage/user-id/5510513)

More information is needed.

You said:
> when the start or completion date of a blocking task is changed, the date of the blocked task is automatically adjusted. Can anyone share a step-by-step guide on how to do this?

When the **start date** of the blocking task is changed, how does that affect the dates of the dependent task?

When the **completion date** of the blocking task is changed, how does that affect the dates of the dependent task?

What is your level of experience with creating Automation Rules?

comments: author: Hernani J?nior
body: I understand automation well, but I'm less familiar with the timeline function. Recently, I created blocking lines on the project timeline in Jira. I would like the date of the blocked task to automatically adjust when the date of the blocking task is changed. However, these blocks were configured directly on the timeline.

![Captura de tela 2024-08-30 102336.png](https://community.atlassian.com/t5/image/serverpage/image-id/344787iDCCC0123CE216243/image-size/large?v=v2&px=999 "Captura de tela 2024-08-30 102336.png")


author: Trudy Claspill
body: Hello [@Hernani J?nior](/t5/user/viewprofilepage/user-id/5510513)

Creating a dependency between two issues in the Timeline should create an Issue Link between them. If you look at the details of those issue you should see information in the Linked Issues section for each one indicating its relationship with the other. Please confirm that is the case. Example:

![Screenshot 2024-08-30 at 8.26.21?AM.png](https://community.atlassian.com/t5/image/serverpage/image-id/344820i53BADEBABE6CE82A/image-size/large?v=v2&px=999 "Screenshot 2024-08-30 at 8.26.21?AM.png")

In the image you shared I don't see issue keys in the relationship box. In the Plans Timeline it is possible to add issue to the timeline, but the issues don't really exist until you Review the Changes and commit them to the related Projects.

Are the two issues in your image unsaved new issues?

Automation rules cannot be run against issues that are not yet committed/created in the project.


author: Hernani J?nior
body: I have two epics that, within my instance, represent phases of a project. Their keys do not appear because I took a screenshot of the timeline, and I'm not sure if the keys showing in the screenshot are relevant to my question. What I really need is to automatically change the dates of the linked items.

How would you build an automation to automatically change the dates of the linked items? Using what is in the screenshot as an example, how would you make it so that when the date of CS-85 is changed, the date of CS-22 is adjusted proportionally with the days added to the original date?


author: Hernani J?nior
body: I want that when I change the date of one item, the date of the next one is automatically adjusted. Using the example from the screenshot, if I change the warranty date, the Go-Live date should also be adjusted. Specifically, when I change the ***target end*** of the warranty, I want the ***target start*** and ***target end*** of the Go-Live to be adjusted proportionally, since the Go-Live depends on the end of the warranty.

![Captura de tela 2024-09-02 113453.png](https://community.atlassian.com/t5/image/serverpage/image-id/345128iE1D3030BB30FDA79/image-size/large?v=v2&px=999 "Captura de tela 2024-09-02 113453.png")


author: Trudy Claspill
body: Thank you for the clarification. I have a few more questions.

In the last image showing the Garantia issue the link relationship says it "is blocked by" the Go Live issue. But in your description you said that the Go Live issue depends on the Warranty issue. It appears that the link relationship is reversed and the Warranty issue should show that it "blocks" the Go Live issue.

Do you use this link relationship the exact same way for all your dependency relationships? When looking at the preceding issue does it always show "is blocked by" the issue that depends on it?

Do you want the Go Live issue dates to change only when the **target end**date of the Warranty issue changes?

Do you want the Go Live dates changed so that the original duration of that issue remains the same?

If the Go Live issue has an issue that depends on it, do you want that issue's dates changed also?

Note that when you are working in a Plan the changes you make are not immediately updated to the issues. This is by design so that you can make changes in the Plan to see how those changes affect your Plan.

Automation Rules can't run against those changes until you commit the changes to the underlying issues. If you change the Warranty issue dates in the Timeline, but don't Review and commit the change, then the Automation will not run and you won't see any change in the dependent issue.

If you want to see the changes in the Plan you have to commit the change to trigger the automation rule.


author: Hernani J?nior
body: hank you for the clarification.

Yes, the Warranty item blocks the Go Live item because Go Live can only occur after the Warranty ends. What I need is for the Go Live date to be automatically adjusted if I correct the Warranty date. For example, if I extend the end date of the Warranty by 3 days, the target start and target end dates of Go Live should also be extended by 3 days. I understand that changes to the Plan need to be confirmed for the automation rule to be executed.

I will ensure that the changes are reviewed and confirmed to trigger the automation.


author: Trudy Claspill
body: Do you want this change to happen only for the Warranty and Go Live pair of issues or for all issues where you set up the same dependency?


author: Hernani J?nior
body: For all problems.

This was just an example.


author: Trudy Claspill
body: For all issues that use the Blocks relationship? Or for all issues that use any link relationship?

Do you use the relationship backwards consistently, as you showed in your example?

You said the Go Live depends on Warranty. When you look at the Warranty issue you should see in the Linked Issues section a heading for "blocks" with the Go Live issue under it; i.e. Warranty "blocks" Go Live. Looking at the Go Live issue you would then see in the Linked Issues section a heading for "is blocked by" with the Warranty issue under it; i.e. Go Live "is blocked by" Warranty.

Instead the relationships show is reversed; Warranty "is blocked by" Go Love. That makes is appear that Go Live has to be done before Warranty.

This is an important distinction, and how you use this linking needs to be consistent because that will be a factor in the Automation rule.

Also, what do you anticipate is the maximum number of issues in a chain; i.e.

A blocks B

B blocks C

C blocks D

etc.

If you changed A then B should be updated. Since B blocks C, when B is updated by the rule then that should trigger the same sort of update on C, and so on. That would make this a rule that takes actions that would cause the same rule to be triggered again. There is a limit of 10 such recursive triggers for a rule. If you might have more than 10 issues chained together, that has to be factored into the Automation.


author: Hernani J?nior
body: For all issues that use link relationships, I need the automation to update all subsequent items. Although I don't have more than 10 linked issues, if there are, for example, 5 interconnected items, when I update the first one, I need all the following ones to be updated automatically.


author: Trudy Claspill
body: > For all issues that use link relationships

I think we are having a failure in our communications.

There are many types of link relationships; i.e.

* Blocks
* Clones
* Duplicates
* Relates to

...as defined *here:*   
*<https://your.base.URL/secure/admin/ViewLinkTypes!default.jspa>*   

Do you expect this to be applied to every type of link relationship, or only issues linked using the Blocks link type?

Additionally the rule will depend on the directions of the links being used consistently.

Are you consistently using the directionality of the link relationship?

When you look at a Warranty issue does it always (currently) show the Go Live issue under the heading "is blocked by", or does it sometime appear under the heading "blocks"?

For issues that depend on Go Live, do those appear in the Go Live issue under the heading "is blocked by" or do they appear under other headings?

**This is an important detail**.

The automation rule can operate correctly only when the link type used is identified and the directionality of the link is applied consistently through the chain of issues.

If you have dependencies like:

Issue X depends on Go Live, and Go Live depends on Warranty

...but you link them together in an inconsistent manner like this::

Warranty is blocked by Go Live blocks Issue X

...then the rule cannot be properly constructed.


author: Hernani J?nior
body: I only use the 'blocks' link relationship. As shown in the screenshots above, I have not used any other type of relationship at any point. I do not use other types of link relationships.

I'm sorry if I wasn't clear before, but what I really want is to build an automation that changes the date of the items interconnected by 'blocks'. If I change the date of one item, I want all subsequent items linked by 'blocks' to be updated automatically, and only those items.


author: Hernani J?nior
body: I want to build an automation that changes the date of items linked by 'blocks'. If I change the date of one item, I want all subsequent items connected by 'blocks' to be updated automatically. That's it. Can you give me an example of automation that works for this case? It can be a screenshot or direct me to some documentation.


author: Trudy Claspill
body: There is still a critical piece of the puzzle that you have not answered - the directionality of the link between the issues. This is important because it will determine which issue is gets updated.

You have said that Go Live depends on Warranty.

Based on the screen image you presented when you view Warranty you see:

"is blocked by"  
-- Go Live

That reads as:

Warranty is blocked by Go Live

Assuming that you continue that pattern, then if there was some issue dependent on Go Live the chain would continue with:

Warranty "is blocked by" Go Live "is blocked by" Some Issue.

The rule will have to find the dependent task. It will do that using the specific text you see where I have used "is blocked by". As the rule tries to walk down the chain of issues, if sometimes that is "is blocked by" and other times it is "blocks" then the rule will not be able to operate correctly.

So, for the remainder of this discussion I'm going to assume that you are chaining the issue as shown above, even though grammatically linking the issues in that way is misleading.

The basic structure of the rule is this:

```
Trigger: When Due Date changes
Condition: Due Date is not empty
Branch: For Related issues / Linked issues: Link type = "is blocked by"
  Condition: Start date is not empty
  Condition: Due Date is not empty
  Action: Create Variable (to calculate the current duration of the dependent task)
    {{issue.Due Date.diff(issue.Start date).days.abs}}
  Action: Edit Issue
    Start date: {{triggerIssue.Due Date}}
    Due Date: {triggerIssue.Start date.plusDays(varDuration.asNumber)}}
```

On the Rule Details page you have to check this box:

![Screenshot 2024-09-05 at 2.22.49?PM.png](https://community.atlassian.com/t5/image/serverpage/image-id/345876iF4B1808E285E6C1B/image-size/large?v=v2&px=999 "Screenshot 2024-09-05 at 2.22.49?PM.png")

When the rule runs it will update the start data and due date of the dependent task. The change to the due date of the dependent task will cause the rule to be triggered again to look for a dependent task for the one that was just changed.

If there are more than 10 issues in the dependency change the rule will stop running with the 10th issue. That is a limit on the number of times rules can trigger other rules in a continuous chain. There are ways to work around that limit, if necessary.

In my example you need to replace "Start date" and "Due Date" with the names of the fields you actually use for recording the starting date and ending date in your issue.


author: Hernani J?nior
body: Thank you very much for the response; now the path is clearer.

However, regarding the directionality, I didn't understand what you meant when you mentioned that it would be the key to the puzzle.

My epic structure works as follows: Initial Stage - Client Parameterization - Development - UX/UI - Go Live and Warranty. Each stage blocks the next one in sequence, meaning the next one only starts when the previous one ends.


author: Hernani J?nior
body: I only use the 'blocks' link relationship.


author: Trudy Claspill
body: Can we agree on the meaning of these two statements?

1. A blocks B.   
   This is equivalent to saying "B is blocked by A".
2. A is blocked by B  
   This is equivalent to saying "B blocks A".

Statement 1 says that A must be completed before B can start. That is the definition of "blocks"

Statement 2 says that B must be completed before A can start. That is the definition of "is blocked by".

The terminology "blocks" vs. "is blocked by" defines what I am calling the direction of the link. It tells you which issue depends on the other issue.

When you create the link between the issues, you choose the terminology to describe the relationship between the issues.

![Screenshot 2024-09-06 at 2.36.29?PM.png](https://community.atlassian.com/t5/image/serverpage/image-id/346065i625B98FE52A708D0/image-size/large?v=v2&px=999 "Screenshot 2024-09-06 at 2.36.29?PM.png")

If you choose "blocks" then you are telling Jira that the issue you are currently viewing (TS-42) must be completed before the issues you are about to enter can be started.

If you choose "is blocked by" then you are telling Jira that the issue you are currently viewing (TS-42) cannot be started until the issues you are about to enter are completed.

Let us say we have these links for TS-42.

![Screenshot 2024-09-06 at 2.39.51?PM.png](https://community.atlassian.com/t5/image/serverpage/image-id/346068i245C2210765914FF/image-size/large?v=v2&px=999 "Screenshot 2024-09-06 at 2.39.51?PM.png")

This tells us that:

1. TS-42 must be completed before TS-46 can be started
2. TS-43 must be completed before TS-42 can be started

The chain of issues from what has to be completed first to what can only be completed last is:

TS-43 \>\>\> TS-42 \>\>\> TS-46

Now let us say that you change the ending date for TS-42, the issue we are viewing. Which of the two issues linked to TS-42 should be updated based on that change? You want to automatically update only the issues farther "down" the chain - the issue that can't be started until TS-42 is complete - which is TS-46.

The rule needs to move through the chain of issues in only one "direction" - the direction from the current issue to the next issue that depends on it, and so on.

How does the rule know you want to update TS-46 and not TS-43? If determines that based on the "direction" of the link. It determines that TS-46 is the issue that needs to be updated because TS-42 "blocks" TS-46.

Does that clarify for you what I meant?

I can't think of another way to explain this.


Tags: cloud

jira-cloud