Issue fields information sync in Jira Cloud
Asked by Christian Isaza:

Hello, everybody,  

I administer a Jira Cloud instance for my company and I was asked to see the possibility to Sync some issues linked to others across multiple projects in the same instance.  

I have been trying to get an automation rule working with no success and would like to get your help on this. Thanks in advance.  

The information I have:  

We have a "source" project which has many issues linked to other issues in other multiple projects. The targets. The issues in the source are linked as "Blocks" to the Target's issues.  

The request is that everytime fields as Status, Assignee, Comments and Due Date are updated, changed, added, deleted, those same changes are reflected from the Source issues to the Target's issues.  

At the moment, it would be only issue to issue, and not issue to many.  

I have tried the rule as you can see in the screenshots. Including changing the Edit issue action from current issue to trigger issue, and the condition from linked issues present directly to issue fields condition Link is not empty.  

Additionally tried the FOR to be set as all issue operations, edit, create, and nothing seems to trigger although I see in the audit logs sometimes that the rule runned successfully or that runned with no actions taken.  

Nothing seems to work, so I would like to get your help on how to resolve this.  

Thanks.  

![Screenshot 2024-09-20 152237.png](https://community.atlassian.com/t5/image/serverpage/image-id/348464iBB6AD36E6E734911/image-size/large?v=v2&px=999 "Screenshot 2024-09-20 152237.png")![Screenshot 2024-09-20 152216.png](https://community.atlassian.com/t5/image/serverpage/image-id/348465iEA93562B9C08B4FA/image-size/large?v=v2&px=999 "Screenshot 2024-09-20 152216.png")![Screenshot 2024-09-20 152153.png](https://community.atlassian.com/t5/image/serverpage/image-id/348466i84B7257CB05826A1/image-size/large?v=v2&px=999 "Screenshot 2024-09-20 152153.png")  

<br />

Also tried "For all issue operations" and specific operations as well, but the result is always the same.


Answers:
author: Robert DaSilva - Adaptavist
body: Hey [@Christian Isaza](/t5/user/viewprofilepage/user-id/5597865) , welcome to the Community!

If I understand your challenge correctly, you're looking to do the following:

1. You want to watch all issues inside your Source Project, Project A, for any changes to the following fields:
   1. Assignee
   2. Due Date
   3. Status
   4. Comments
2. Any time one of those fields changes in any way (either data is added, deleted, or updated), you want to copy the change to a linked issue. Of note, that issue is linked as "Blocks" on the source issue.

If I've got that right, then your automation rules are close! You're missing the "For: Linked Issues" action branch. Here's a screenshot of what your automation should look like.

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

A couple things to note:

* You'll want to use the "For: Linked Issues" condition block
* I would recommend adding in conditions before the "For" block to restrict this to the project that triggers these changes
* Both projects should be "Company Managed" and sharing the same Statuses. It's important they share the same back-end Status IDs. The best way to accomplish this is to ensure both projects are using the exact same Workflow, or ideally Workflow Scheme.
  * If the statuses are different between the projects, the transitions may pose a challenge.
  * In the workflow, you will want to make sure any status can transition to any other status. If the transition cannot resolve, then the automation rule will not properly execute.
* You may want to consider locking down the permissions on the destination projects, so that only the Automation for Jira app can make changes, and your trigger project ends up being the "source of truth"
* When selecting the values to copy, you want to select "Trigger Issue", as this will copy the data from the issue that started the automation, in your case, from the triggering project.

Let me know if that works!

Robert

comments: author: Christian Isaza
body: Hello, Robert!  

Thank you so much for your response.  

Yes, issues on Project A would be the blockers of the issues in the other projects. And changes would be applied in Project A to be reflected in the other projects.  

Thank you for the explanation, at this time I am trying your changes considering all the details provided (the workflows and permissions).  

Once I test it out, I will post again if it was successful.  

<br />


author: Christian Isaza
body: Hey, [@Robert DaSilva - Adaptavist](/t5/user/viewprofilepage/user-id/3984541)   

Thank you for your help. For the Assignee, Status and Due Date it is working smoothly.  

I just wanted to ask how would it be for the comments? The same principle: all comments that are added or edited (at least added), how could I copy them into the linked issues?  

I tried:  

<https://community.atlassian.com/t5/Jira-questions/Add-automation-copy-cloned-story-s-comment-into-story-it-s/qaq-p/2258868?lightbox-message-images-2258968=237999iBB71A1BEDF5C7A22>  

<https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/#--issue.comments-->  

Thanks


author: Robert DaSilva - Adaptavist
body: [@Christian Isaza](/t5/user/viewprofilepage/user-id/5597865) Comments are more challenging as they can be edited. If you want only the original comment as it was written, you can use the same logic, but instead use the "Comment Added" trigger.

I would also recommend restrictions on the permission scheme to prevent comment editing, to ensure things stay connected.

As an aside, I would re-evaluate your use case, and determine if sharing the tickets using a cross-project board is a better way to ensure internal alignment. Duplicating this data is not generally considered best practice inside of Jira.


author: Christian Isaza
body: Hi [@Robert DaSilva - Adaptavist](/t5/user/viewprofilepage/user-id/3984541) thank you again.  

Can you please clue me in why this would not be a best practice?  

The reason behind our will to implement this is because the people working on the source and target projects have the same tickets in both sides (for business/StakeHolder's reasons) and want to avoid manually updating them since they could be some times 20+ tickets in one single change (I mean, 1to1 but multiple).


author: Robert DaSilva - Adaptavist
body: [@Christian Isaza](/t5/user/viewprofilepage/user-id/5597865) Generally Jira works best when all parties involved are looking at the same ticket.

I'd be curious as to why there are multiple Jira Projects that aim to track the same pieces of work. The general practice is that pieces of work are unique, and exist once in an instance. And then any users that need to be party to that are either "Watching" those individual tickets, or are looking at Project Boards or Dashboards that have filters that display only the content they care about.


Tags: cloud

jira-cloud