Automation rule on status change of jira ticket.
Asked by Neeta Dubey:

Hi All,

I need help in creating a jira automation.

Scenartrio:

I've a ticket in Project A and clone of that ticket in Project B.

Once the status change of that specific issue type ticket it should change status of that cloned ticket in project B. Is it possible to achive?


Answers:
author: Marco Brundel
body: Hi [@Neeta Dubey](/t5/user/viewprofilepage/user-id/5287425) ,  

<br />

In an automation rule you can specify Issue transitioned as the trigger. And in a rule you can include a Branch where you then define an action in the branch for, for example, the linked issues.

Can you continue with this information?

regards, Marco

![Screenshot 2024-04-04 at 14.16.25.png](https://community.atlassian.com/t5/image/serverpage/image-id/316302i872CC8E5EC2DB1A0/image-size/large?v=v2&px=999 "Screenshot 2024-04-04 at 14.16.25.png")


author: Dexter de Vera
body: Hi [@Neeta Dubey](/t5/user/viewprofilepage/user-id/5287425) ,

You need to create 2 automation for creation of clone ticket to and updating status.

Automation 1:  
When: Issue created

Condition: Issue fields condition - Project - Project A

Then: Clone issue - Project - Project B (You can add more fields changes if you want)

Automation 2:

When: Issue transitioned - leave it blank status from and to so all every changes in status will trigger the automation

Condition: Issue fields condition - Project - Project A

Branch rule / related issues: Branch rule / related issues - "Type of related issues = Linked Issues" and "Link Type = is cloned by"

Then add Action in the branch - Transition issue - Destination status - Copy from trigger issue.

NOTE:

Both project should have same workflow.

Dont remove/update the linked issue because this is the way to track the clone issue.

The scope of both automation should be Project A and Project B (you can see this under Rule details)

Hope it helps!

comments: author: Neeta Dubey
body: Hi Dexter,

thank you so much for info it works well when cloned issue is in the same project although I've included both the projects in scope.

it faild when I did below -

I created defect in Project A, cloned it, moved the clone to Project B, change the status of the mqms defect in Project A, and the status of the Project B defect didn't change


author: Dexter de Vera
body: Hi [@Neeta Dubey](/t5/user/viewprofilepage/user-id/5287425) ,

Do you create the 2 automation? First automation will directly create clone issue in Project B. No need to manually clone then move to project B. And the second automation is the one will update the issue clone base on the transition made in project B.

Maybe you can show us the 2 automation you made so we can check it.


author: Neeta Dubey
body: Thanks Dexter, When I move ticket from Inprogress to Implemented, I've a transition screen and some validators, which is same in both the tickets, would that we causing the issue.

Also, I didnt automate it because I don't need to clone issue every time, is manual cloing is a problem![snip 3.png](https://community.atlassian.com/t5/image/serverpage/image-id/316623iFF7A797A84564328/image-size/large?v=v2&px=999 "snip 3.png").

Also, i modifed the condition to "Clones" as I would be making changes in the cloned issue.

This works well when I dont have any transition screen like moving between to do to backlog.


author: Dexter de Vera
body: Can you screenshot the auditlog in automation. And let see what happen in automation process.


author: Neeta Dubey
body: They share the same WF and transition screen, although the values are not getting copied in the destination project. If there is no validation then rule works well.

![error.png](https://community.atlassian.com/t5/image/serverpage/image-id/316729i8B689B509C8F8889/image-size/large?v=v2&px=999 "error.png")


author: Dexter de Vera
body: Error is because of the Fix version and Risk are required. So you may create new workflow without that validation for your Project B (if this is not required in your project B). You can just copy the workflow scheme and workflow of Project A. then update the new copied workflow, remove the validation then update your copied workflow scheme, align the new workflow in scheme then use the copied scheme in your project B. So the result will be Project A is the only one that have validation.


author: Neeta Dubey
body: Thanks for your quick reply Dexter. I really appericiate it however if I remove validation for project B then it may leave to inconsistency in ticket data.

In project A ticket, All fields will have relevant information.

In project B ticket, those fields on which validation worked in Project A would be empty in project B.

Let me know if it not work in the above way.


author: Dexter de Vera
body: If that so, you need to copy too the required field value to your copied ticket. So it will not be empty. It got an error because the field is empty on your project B ticket.


author: Neeta Dubey
body: Hi Dexter,

Thanks for your prompt response,

but all different transition have different validators, Could I put all validators at once,

also, how I could I copy mandatory fields from project A ticket to project B?


author: Dexter de Vera
body: This will be complicated because you want to sync everything. Every changes in field , status etc. And it will affect the performance due to plenty of automations running every changes. Maybe you need to adjust it. Let your team just access the linked issue (clone) to see details about everything. Or just work in 1 project if every proccess should be the same. Also if you are willing to add plugin. There are plenty of syncing ticket app that you can use to sync issues like [exalate-jira-issue-sync-automation](https://marketplace.atlassian.com/apps/1213645/exalate-jira-issue-sync-automation-more?tab=overview&hosting=cloud) etc.

Hope it helps.


author: Dhiren Notani_Exalate_
body: Hi [@Neeta Dubey](/t5/user/viewprofilepage/user-id/5287425) ,

Thanks for posting your question here on the community.

I am Dhiren, one of the Solutions Engineers working at Exalate.

Although it might be possible to do this via Jira Automations, but the more robust and flexible way to achieve this is using a dedicated and fully decentralized integration solution like [Exalate.](https://marketplace.atlassian.com/search?query=jira%20issue%20sync)

Exalate uses Groovy based scripting engine which offers you limitless customizations, and not only you can sync issues seamlessly, but with that you can choose what fields to map (even custom fields of any type can be synchronized).

Thanks, Dhiren