It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to keep two JIRA issues' status in sync automatically?


I have two JIRA issues from two different projects and I need one issue‘s status automatically changed if the status of the other issue gets changed. I tried to ‘Link issue 1 to issue 2’ and it did not work. Do you know if there is a way to achieve this?

9 answers

Hello there,

This is Riddhi from team Exalate.

I would like to let you know that Exalate is made for this. It allows to sync information bi- and uni-directionally between multiple Jira instances. Or separate projects in your local Jira.

It's mega flexible, you can sync all types of information, including comments, attachments and custom fields. You can control what to sync and what not, and much more ....

I hope this answer helps.

Thanks :-) I will look into Exalate to see if it will cover my scenarios better.

@André Trommestad, just to let you know there are multiple apps like Exalate in the marketplace which work in similar ways. If you want to get the whole list, go to the marketplace to search for issue sync apps.

I'm not aware of any plugin that can do this. for sure this could be done by an event listener. event listeners can even be implemented in groovy, just look here The event listener would need to check if any of the two issues changed the status. If yes one would have to execute the same transition on the other issue. To detect the status change easily one could define a dedicated event for that and create this one in the workflow. That way you just need to check if this specific event was thrown.

We are looking for the same functionality. Has anyone already implemented a groovy script that does this?

You'll need to do some scripting to achieve that, either by using listeners or post-functions. You could use Groovy or JJUPIN or anything that allows you to customize the workflow.

The reason why you won't find that ready-made is because you can have different workflows for the two issues and transitions are the only "legal" way to change the status of an issue. What happens when for issue A you have Status1 -> Status2 -> Status3 and for issue B Status4->Status5. There are a lot of variables in this use case, so it's unlikely that you'll find a solution that will work out of the box.

Please use the add-on "Status-Sync for distributed workflows" for JIRA available on the Atlassian Marketplace to set status of all subtasks, related user stories of Epics or linked issues on one hand or the related parent on the other. You can configure the link direction to determine the target issue(s) as well as the workflow transition to be executed by the first (e.g. start working) or last of the sub tasks (e.g. finished work) or the parent issue (e.g. in case of canceled or postponed).

For detecting the change, you could either use Dieter's answer or use external automation to query the JIRA change tables. For updating the second JIRA, you can JIRA Command Line Interface progressIssue or similar techniques. I prefer the external automation route as it is more flexible in handling many similar situations including 2-way changes. Using Bamboo (for instance) to run the automation makes it easy to control (to handle outage cases), keep logs for problem determination, and provide notifications.

Thank you both for your responses. If we have to do extra work to achieve this, I wonder what kind of 'link functionality' that JIRA 'link issue' can provide us besides information only? One more question regarding the type of link issue, it seems that the 'Associate' and 'Depend' are about the same, 'Duplicate' and 'Clone' are the same? Does anyone find the usage of linked issue is helpful to them and how?

Linking issues is really a different questiion. The concept is very helpful for many installations. You can add your own link types like linking requirements to development issues for instance. Duplicate means that the underlying issue reported is essentially the same and usually a fix for one with fix the other. Normally, you fix one issue and then close the other issue as a duplicate (reason code) and link them with duplicate. Cloners is different. It says that one issue was copied from another issue for some reason like creating additional tasks for someone else or copy work to a new iteration that was not totally complete in an earlier iteration.

Linking of issues is very useful to establish the relations between issues. This gives traceability of related issues. And the type of links are just for the readablity to clearly indicate what type of relation exists between the issues.

Also a third option (apart from event listeners and command line interface) is to use the SOAP interface of Jira and it is pretty easy to keep the issues status in sync

0 votes

I've use Project automation for this and it works fine for my projects. 

You have to add automation for each status change.

ex: WHEN "a linked issue is transitioned" -> IF "Linked issue matches status = "In Progress" AND "Link type matches clones" -> THEN "Transition issue Start Progress"

This works fine when the workflow in the two projects the issues belongs to are the same. If not it will be a bit more work setting up the project automation.  

Suggest an answer

Log in or Sign up to answer
This widget could not be displayed.
This widget could not be displayed.
Community showcase
Published Apr 09, 2019 in Portfolio for Jira

Portfolio for Jira 3.0 is here!

The wait is over... Portfolio for Jira Server and Data Center 3.0 is now officially here! Platform releases offer Atlassian an opportunity to shift our strategy, make bold predictions about t...

1,279 views 12 24
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you