Clone an issue without cloning workflow?

[robert.hays]

I have a published process where my users are supposed to clone tickets so that they can work on them in a separate board.

Problem is, they clone the ticket and the workflow assigned to the cloned ticket is also cloned. 

This means that our board does not track the tickets, due to our board having a different workflow.

We cannot make our board match the workflow of other boards because several teams are using completely different workflows and we need to have ONE for our boards.

EXAMPLE:

We acquired multiple companies, all with their own Jira instance.

We migrated their Jira instances to our own. But they retain their teams and their workflows. 

We have a team (X) and our own task type (D). 

We clone tickets from the engineering teams because we want to do our own work on them on our own board and on our own time, to ensure we do not mess with their sprint metrics.

We will clone a ticket from a team that is in a state of (pending), for instance. The workflow will have the ticket workflow of Pending - Drafting - Research - Done.

We clone the ticket, and then move it to team X and change the task type to D.

When we look at the cloned ticket AFTER moving it, the ticket is still in Pending, and still has the same workflow associated with it.

We do not use any of the workflow steps in the original ticket, and therefore the ticket will not show up on our To DO -- In Progress --Needs Info-- In Review -- Done workflow board.

So, I was trying to replace the workflow status in this instance, for example, where the status of Pending to a status of To DO, and then the workflow would follow.

How do we remove a workflow when creating a clone?

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

Cloning an issue does not clone the workflow.  It clones the issue.  The new issue will exist in the same project and, of course, as a clone, will be of the same issue type.  The project and issue type being the same means that it will be configured to use the same workflow.

You cannot remove a workflow if any issues are configured to use it.

I think what you need to look at is moving the cloned issues after you've cloned them.  You probably need to change their type or move them to another project in order for the other team to work on them.

However, I cannot recommend that - moving issues is clunky and can need a lot of effort, it is not intended to be a part of a regular process, it is for housekeeping, migration and genuine "created in the wrong place" incidents.  Clone and move is not really what you should be doing, your process should be to create new issues in the right place when you need them, and link back to the issues that prompted them.

[robert.hays]

OH> Yes, I am moving them to a different project and I change the task type. But the workflow is not matching up to the workflow at the project and task type.

[Nic Brough -Adaptavist-]

You acquisition is very good reason for "move"

But it has consequences.   Every issue type in a project has its own workflow.  (May well be the same as all the others, but it might not)

You need to look at what you are importing and decide how you want to handle it.  Is it the same way you currently do it?  If it is, how are you going to map the status into your current process?  Pretty much the same question if it is wildly different.

Cloning issues is a nightmare, stop doing that, you need to move to a place where one customer raises one issue and your team deals with that one issue.

[robert.hays]

The tickets we work on are owned by a different team. Won't moving them mean that the other team will not longer see them?

Or should we do a clone and then MOVE the cloned ticket?

[Nic Brough -Adaptavist-]

Yes, that's why you really don't want to be cloning and moving.

[jeremiah_landi]

@robert_hays What are you trying to accomplish?

An issue can exist on multiple boards within the same project and you can have workflow flip the issue between boards based on properties (eg. labels).

I currently run a twin board setup with my teams off the same Company Managed Project. They are a design board and a development board with a release board handled by Trello.

I use the label "UserExperiance" to flag the design tickets then a custom JQL to exclude it from showing up in the development channels.

I have also run projects that have five to six boards; I think it all really comes down to backlog management and task completion. Let me know if this helps but the "boards" driven by JQL have always been great.

Example: project = [project name] AND labels = userexperiance ORDER BY priority

[robert.hays]

We acquired multiple companies, all with their own Jira instance.

We migrated their Jira instances to our own. But they retain their teams and their workflows. 

We have a team (X) and our own task type (D). 

We clone tickets from the engineering teams because we want to do our own work on them on our own board and on our own time, to ensure we do not mess with their sprint metrics.

We will clone a ticket from a team that is in a state of (pending), for instance. The workflow will have the ticket workflow of Pending - Drafting - Research - Done.

We clone the ticket, and then move it to team X and change the task type to D.

When we look at the cloned ticket AFTER moving it, the ticket is still in Pending, and still has the same workflow associated with it.

We do not use any of the workflow steps in the original ticket, and therefore the ticket will not show up on our To DO -- In Progress --Needs Info-- In Review -- Done workflow board.

So, I was trying to replace the workflow status in this instance, for example, where the status of Pending to a status of To DO, and then the workflow would follow.