nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Using automation to move issues between 2 service projects

Nico Van Hoof

In our company we have a few different service desks with their own agents to follow the issues. But sometimes clients misjudge the problem and log it in the wrong service desk project.

So in these cases I move the issues manually, though I wanted to streamline this and make an automation rule the agents can trigger to move this issue instead of sending a request my way to move the issue saving time.

However moving isn't possible through automation and so instead I use the solution to clone and then delete the original issue. However by doing so I did notice that tickets clones this way lose the status of a service request and the client/reporter don't see the newly cloned issue in their portal and also don't get any notifications.

I was wondering if there is something I have to set specifically in the clone action to make sure the newly cloned issue is still handled as a service request/incident logged by the client.

Accepted answers

All comments

Laura Humphries_y6xzot

Hey @Nico Van Hoof

Welcome to the Atlassian Community!

First thing to check, when cloning the issue, are you also setting the Customer Request Type? As without one, customers will indeed not be able to see their requests.

Mark Higgins

hi @Nico Van Hoof

Welcome to the Atlassian Community!

I've created something similar, recently, and it looks like this:

Screenshot 2025-02-07 085017.png

When you click on the 3 dots you are presented with a choice to Set the field or Copy the field.

Let me know if this helps.

Mark.

PS. My preference was to cancel the original, rather than delete, so that the record was there, but that's just a preference.

Luka Hummel - codefortynine

Hi @Nico Van Hoof and welcome to the community!

Since Jira automation doesn't support directly moving issues, your current clone-and-delete method is a common workaround.

If you are willing to try a third party app, our app Deep Clone for Jira offers a powerful solution here. It allows you to clone issues across projects while maintaining essential attributes like the issue status, customer request type, comments, attachments, and more. This ensures that the cloned issue remains visible to the client in their portal, and notifications can be configured to trigger upon cloning.

Nico Van Hoof

I did try to add the request type but doing that in the clone step it says that it can't be edited and that you need to use another action. But when I try to add that step to the automation it will change the request type of the issue where the automation is triggering and not the clone.

Leaving it in the same state as before where the client loses the ability to track it in the portal and receive updates.

But this gives me an idea to see if I can setup another automation rule on the receiving end that triggers when a linked issue is made that tries to copy the request type. As it is indeed losing the request type while cloning.

Laura Humphries_y6xzot

Another way, off the top of my head, would be doing the following in your current automation rule (the one that clones):

Clone the issue (which you already have)
Create a branched rule for the most recently created issue
Set the customer request type (within the branch)

I haven't tested it but it would be a more manageable solution to have it all in one rule. Creating a separate rule would also work.

Just an idea!

Dusty Brossart

For anyone that stumbles across this, these two articles were very helpful:

https://support.atlassian.com/cloud-automation/docs/move-an-issue-to-another-project-using-automation/

https://support.atlassian.com/jira/kb/how-to-clone-an-issue-and-update-the-request-type-using-automation-in-jsm-cloud/

My only issue is that neither JSM project will send a notification to the customer/user when the request is created. My current workaround is to add a public comment after the issue has been cloned, so that it will notify the user of the new request link.

QMSpot _ Patrick Gehlich

2026 Mai and still a Problem?
Thats sad!

i also need to move issues from one JSM to another JSM per Automation.

We only have one Support Email Adress.
I need to separate the Customers from their domain from the email adress to another JSM.
Automation can check the Domain.
But cannot move the issue to another JSM Space.

We also need the Attachment and also need direct Automatic answer from JSM, back to the customer.

Do i need to create a new M365 licensed Mailbox and work with Exchange rules?
route the mail directly from our support@ to Customer1.support@?
Than i connect the customer1.support@ to the dedicated JSM Space?

So the customer writes initially to support@ but from there we continue working with customer.support@ ?

It´s tricky ^^

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management