Automation rule Move ticket to another project

[Sama Mohamed]

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.

[Nic Brough -Adaptavist- · Accepted solution]

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]

Thank you!

[Stacy S]

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.

[Nic Brough -Adaptavist-]

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

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.

[Nic Brough -Adaptavist-]

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]

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.

[Karri Adkins]

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.