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; } } }

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.

Accepted answers

Nic Brough -Adaptavist-

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.

All comments

Nic Brough -Adaptavist-

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

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.

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