Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Automation rule Move ticket to another project

Sama Mohamed
Contributor
June 21, 2022

automation that moves tickets from one project to another project. You need to use JSM Playground and R&D Assistant project.

Keep in mind when the ticket is moved it should keep the reporter and request participant the same. There is no need to move the assignee.

1 answer

1 accepted

0 votes
Answer accepted
Nic Brough -Adaptavist-
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 22, 2022

Automation does not have a function to move issues between projects.

Moving an issue is a complex process that changes the structure of an issue, and as such, you have to check that it is possibble, and usually ask the user to add or amend data on it, and confirm that they understand some data may be lost.

It should never be part of a process, and it should never be automated.  It is for genuine mistakes and housekeeping/re-organising.

Sama Mohamed
Contributor
June 26, 2022

Thank you!

Stacy S
Contributor
February 2, 2023

Hi  @Nic Brough -Adaptavist-, I understand your point, but there are use cases where intake is controlled and thus it would be desirable to be able to automate moving tickets.  In our use case, we're trying to build a single point of contact/intake project for a team that interacts across the entire company, then move tickets with clear destination locations to their respective boards using rule automation.

We're currently building it as a team-managed project (but it could easily be changed to company-managed, that just places more burden on our company admins).  We have the issue type forms designed to mirror the field values of the desired project, so we should conceptually be able to move the tickets with no errors or issues, because we control what's collected. 

I understand that there is a risk that a change made in the destination board that isn't made in the project with automation could cause issues, but as long as it failed safely (i.e. the ticket was created but not moved, with a noted error message), I don't see why that wouldn't be an acceptable outcome.  Right now, we're having to use the "clone" feature instead, which has the same issue/outcome (error if the fields don't map), but creates 2x as many tickets (and fails poorly, in that it just ignores the "Clone" step).  Since create is separate from move, it seems like the ticket shouldn't be lost, even if the "Move" step fails, so it doesn't seem all that different than "Clone".  Perhaps I'm missing something though.

 

NOTE TO EDIT: Since JIRA Cloud also permits adding fields from company-managed projects to team-managed projects, the one risk I mentioned isn't even an issue when that occurs, so permitting automated CLONE but not permitting automated MOVE makes even less sense when destination project fields are used.

Like # people like this
Nic Brough -Adaptavist-
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 3, 2023

<grumpy-Nic mode on>

No., there is never a case where moving a support issue to a development issue is right.

In Jira, this will destroy the customer request, it makes it look like you have deleted the request they have raised, and destroyed the communication channel with them.  You are doing absolutely the right thing in saying "the developers need to do something with this", but failing your customers by "deleting" their issues.

<grumpy-Nic mode off>

Please, use "create linked issue", not try to clone and dissociate, or move.  You do not need to worry about fields or anything else if you use that.

Stacy S
Contributor
February 3, 2023

Hi @Nic Brough -Adaptavist-, the use case I mentioned isn't a "support to development" concept, for clarity, it's just a central intake board for different types of requests that (for a few use cases) we move/clone tickets to correct boards. 

While it would be nice to be able to just tell users "go to such and such board" for a particular ticket type, they don't always know that's where they should go, especially if it's a board with which they maybe need to interact only once a year (e.g. reporting a product vulnerability).  I will read up further on "create linked issue" though, per your feedback.

We have already identified a configuration that I believe will enable us to do what we need, I just was stating my opinion that there doesn't seem to be much of a difference between moving and cloning re: the complexities that need to be addressed (e.g. required fields addressed), so it didn't make sense to me that the system permitted automating one but not the other.

Like # people like this
Nic Brough -Adaptavist-
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 4, 2023

So the question there is why you have set up a system where people are not directed to the right place to raise things.

It makes perfect sense to not be able to automate things that should not be done automatically!

kristine.daniels September 6, 2023

We have the same use case Stacy S.  We have a consistent place where all intake of issues occurs, then we move those tickets to the appropriate project teams for resolution.  

Cloning tickets breaks the linkage and forces someone to have to open the ticket to find a linked ticket.

Please allow us to automate the processes we need.  We can assume/mitigate the risks.

Like # people like this
Karri Adkins
Contributor
September 27, 2023

I also have the same intake problem to solve.  The inability to provide filters across more than one JSM project is inhibiting, and my company does not want multiple "I have a bug" entry points from each areas across the org.  I propose looking into having a single intake JSM project and moving based on entry criteria to eliminate multiple points of entry.

One thing to keep in mind if companies choose to keep request types such as "Report a Bug", "Question or Comment" the same across the all JSM help desk areas, why do we have to create and include that in multiple help desk projects?   JSM should be able to do intake and allow automation to move things into the correct queues.  That saves time and provides a more streamlined approach to comment request types. 

Like Stacy S likes this
Marc
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 24, 2024

Same use case here.  We need one point of entry for many customers in many organizations to submit a request.  From there, it makes sense to leverage Automation to move the request to the right teams/boards so that the customer link isn't broken.  We have the ability to mitigate the risks and ensure that necessary information is maintained on the move.  We also have the ability to fix the automation if the move isn't set up correctly.

By refusing to meet this need, we are pushed to other solutions.

Like Channy Tremblay likes this
Channy Tremblay
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
October 24, 2024

Violently agree with everybody except Nic here. 

Clone + Delete (as per Move an issue to another project using automation | Cloud automation Cloud | Atlassian Support) is a stupid workaround. 

Not even talking about how clone sucks and ppl need to buy deep clone plugins.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events