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.

[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.

[Mark Higgins]

hi @Nico Van Hoof 

Welcome to the Atlassian Community!

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

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.

[Laura Humphries]

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.

[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]

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

1. Clone the issue (which you already have)
2. Create a branched rule for the most recently created issue
3. 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!