Moving ticket to another Jira project (Software) using automation

[Ashish Bajaj]

I tried to create an automation job, where if the field has a specific type selected (from checkbox field) then move the Jira ticket to another project backlog. But it gave the below error when the automation ran:

Error: com.atlassian.jira.plugin.system.customfieldtypes:multicheckboxes

I think it was as the field I added condition on: had a checkbox where the user had to select the team assigned. I made sure I selected one team but still I got the error and the ticket did not move to different project.

I have two questions:

- Is it possible to move the ticket to another project using automation?

- If Yes then how to get rid of the above error, I cannot go to radio buttons as there would be multiple teams involved sometimes in the ticket.

If not is Cloning the only option? by this way there would be two tickets and we don't want to create duplicate tickets as it would stuff up our reporting.

[Stanley Duback]

I have multiple automations that I build myself for cross project collaboration or deferring issue types to another team.

I accomplish this myself by use of workflows. I am a fan of cloning the issue rather than moving the issue out of the project completely so that you dont lose out on the information and history of where the ticket started. I also develop statistics for how many tickets teams deffer to each other for purposes of improving workflows, communications and training.

Instead of workflow being "Done" is usually build a workflow that says "Move to "X" team"

When cloning an issue, you are allowed to select the project that it is clone into. [A different project than originally exists in]

A couple of things I do is make sure to set the field description as {{issue.description}} so that the body of the ticket comes across as well.

You also have to make sure that the issue type you are setting the issue that is copied over to also exists in the project that it would be going to.

One of the things I do as well is set the linked issue to link itself to the trigger issue.

[Dhiren Notani_Exalate_]

Hi @Ashish Bajaj ,

Thanks for posting your question here, I am Dhiren from the Exalate Team.

Yes, it could be possible to move tickets with Automation but there is a better method to do that which is using a dedicated integration solution like Exalate.

Exalate not only helps you by moving the issue, but it can actually sync that issue to a different project so you can have a near-to-realtime bi-directional integration between multiple projects.

You can map any system/custom field easily and write your own logic for synchronization using the Groovy based scripting engine provided by Exalate.

I understand that it might be a problem for you to maintain duplicate issues, but you can still filter them on the basis of a project for Reporting.

Btw, it's also possible to delete the original issue by making a Rest API call from within Exalate Script!

Do let me know if you have any questions.

Thanks, Dhiren

[Luka Hummel - codefortynine]

Hi @Ashish Bajaj

I'm Luka from codefortynine.

If you are willing to use a third-party app, our app Deep Clone for Jira can make it easy to move your issues between projects using Jira automations.

Deep Clone allows for the integration with Jira Automation through the use of post functions and global looping transitions. This involves adding a global looping transition to your workflow, adding a Deep Clone post function to this transition, and then creating a new Jira Automation rule that triggers this looping transition. This setup ensures that you can trigger a Deep Clone via Jira Automation without changing the status of an issue.

[Diana_Architect_ZigiWave]

@Ashish Bajaj hi. I see that the others have already mentioned how to execute the Automation so that it works. In case you decide to explore alternative ways to connect, transfer data and keep in sync your Jira instances - feel free to check out ZigiOps at the Atlassian marketplace. 100 % no-code, it does not save any of the data that's transferred between the Jira instances. It can easily be customized to fit various use cases (not just ticket transfer) and offers full control over each step of the bi-directional integration. You can try it yourself via the Free Trial.

Regards, Diana