No, you can't do that.
The workflow an issue is following is tied to the issue type. So you can't change to another workflow on an issue. You CAN change the issue type, and if the target issue type has a different workflow, then the issue will follow the new workflow.
There's nothing in a workflow transition that allows you to change the issue type though. It's quite complex to code for because you have to consider all the potential incompatibilities and data migrations.
I see this question referenced around the boards. I believe what Ben was after was the ability to have an issue or a card transition from one workflow to another separate workflow, so that the items can complete the lifecycle they are currently in.
So If I am working on a bug/issue and complete my process on it, I may be able to pass it into another workflow for another team to complete their work against it before closing it.
I see this useful if a Scrum team(s) are working in a shared QA (or team) environment. Maybe a team finishes their work, gets final sign off from the Product Owner (PO), moves it to "done", and upon that story completing there is another story that starts a lifecycle somewhere else (i.e. QA testing).
Does this make sense?
I am new to workflow in JIRA and also looking for an answer on this. I have used systems like OnBase, ImageNow, etc. that have this type of functionality.
I am still shoulder deep in reading and learning though and know this answer is quite old.
My original answer stands, and it's *Very* simple. A workflow is a process an issue follows. It's nonsense to say "another workflow" because that just tells me you've split a single process up pointlessly. Your point about the flow you have is valid, but you answer your own question. "a team finishes... moves to done... *and another story starts somewhere else*". That's not "moving to another workflow", that is "creating a new task to be done". Whether that new task follows a different process is irrelevant, it's a new piece of work. Workflows don't change. It's nonsense. Or if they do change, it's a broken workflow that does not usefully represent your real process. What you're really looking for is "as a result of X, create more items to work on". If you've got access to any coding (e.g. script-runner), then it's a doddle - create a post-function that creates a new issue when someone uses the "close" transition on the first one.
Nic, Very valid points and I'll have to remeber this trick. I have to think on this more. I am worried about creating clutter by copying the card. It would be nice if I could just have a card exist in multiple workflows within a lifecycle without having to create a new card and copy all the information to it. I'll have to read more into this.
It's a logical impossibility for something to exist in more than one workflow. Either there's a process (workflow) it is following, or it's not something that follows a process. (Actually, you can do it on a quantum object, but then you've got the massive problem that you can never know what status or workflow it is actually in, until you make a decision, and then it's in a single workflow)
Sorry, I hit enter too quickly. What you should be looking at is if the item *really* needs to have a single instance - if you think "it needs to have more than one workflow", then you should merge the workflows. The item can only ever have one status (otherwise it's useless), and that means it can only exist at one point in the entire process.
I'm new to JIRA but not new to workflows. Nic, I find your answer dismissive and conceptually unsound. It's one thing to say it can't be done in JIRA, but quite another to say it's invalid. The same piece of work may have different meanings to different teams operating at different levels of abstraction. For example, say I'm a lawyer who needs to send documents across the country as part of my workflow. Say there's a secure logististics department in my company tasked with actually transporting the documents. Ideally, I would transition the issue to the "In Transit" step, which would move it to the logistics team's workflow which would have steps like "Received", "Sorted", "Transferred to Carrier", "Delivered", etc. all of which are beneath my workflow's "radar". Some of this seems possible in JIRA with a trigger/webhook that would programmatically create an issue in the child workflow, but that merely confirms that JIRA is yet another piece of enterprise software that needs to be expensively customized to meet the needs of a demanding client.
I'm sorry you find it dismissive, but what you've described is still effectively a broken process. "Moving things between workflows" is an anti-pattern used when people don't really understand their process or have tools that don't report it effectively. Plus, if you do it properly and use a couple of simple boards to watch it, you can do your "workflow's radar" in reporting. Or you could subtask the stuff that's not in your radar.
When I started with Jira about a year ago I was also new in Jira but not new in workflows. And it was always a puzzle how to maintain multiple statuses of the same document based on workflows attached to a different prospective (legal vs logistics).
In reality it was an issue of the broken process design (as mentioned by @Nic Brough [Adaptavist].
It is actually wrong to think about the workflow of the thing (document, product etc.). The workflow is a process - and has to be described in the process terms aka case, issue. That process works on the document or multiple documents and involves multiple activities. The case resolution may indeed require multiple distinct macro steps, each of which would have their own activities (or tasks) tracked via their own workflows, assigned to their own teams and work on and produce their own artifacts.
@Austin Moran, think about work queue. In your example, the logistic team would monitor for what is in their queue (which documents need to be delivered) regardless from which case the document comes. For them it is a simple list of tickets of the type "Deliver Document". The ticket appears in the logistics queue after the legal department finished their ticket - to prepare the document. Neither of these tickets is the case itself.
What is the source of confusion in the Jira world is its flatness - with exception of sub-tasks everything is an issue (sub-task is an issue as well but at least the terminology is not ambiguous). At the same time the issue may represent the assignable activity (a ticket for the task) or the case (a long running business workflow reportable on the level of resolution and not queueable for the particular activity).
Knowing Jira better now than a year ago, I can say it is implementable in Jira but not out of the box - either with support of scripting or other add-ons you can spawn the child ticket upon transition of the parent case.
Or you can get even fancier - when the issue for the case is created, you can follow the prescribed template to create child tasks. Upon appropriate transition of the child task, you would transition the parent task, which in turn would trigger the transition of the next child task.
The definition of the parent/child is up for grabs - either through links of the certain kind or task/sub-task relationships.
Some of this functionality even available out-of-box between Jira Service desk request (aka overarching case tickets) and Jira Core or Jira Software tickets (assignable activities).
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot