We have a next-gen project version of JIRA. I see that there is no per project workflow setting whereas there is one per issue type. That is fine but I have a certain workflow defined which I am not able to copy it to the workflow each issue type. It seems like I have to redraw the whole workflow for each project's issue type. Can you help here?

We are also trying to do this. We have created the new Workflow. We have also created a new Workflow Scheme, and Associated the Issue Type we want to use with this Workflow Scheme. Despite this, the new Workflow Scheme is in the "Inactive" section (despite it being associated with an Issue Type). If we instead check under Project Settings -> Issue Types, this new Workflow is NOT associated with the Issue Type in that table we can see, again despite us having associated the Workflow Scheme with this Issue Type.

Why is it not possible to associate the correct Workflow from Projects -> PROJECT NAME -> Project settings -> Issue types? This is where you see an overview of Workflow, Field Configuration and Screen for each of your Issue Types, so this would be a great place to be able to edit and change these associations.

So does this mean that, for example, creating a workflow to be used with a multitude of projects is not possible with next gen projects? This would be rather frustrating because we need to set the same workflow on multiple projects that will then be shown in the same kanban board together.

Also it seems like when adding the newly created workflow states to a multi project board as another lane all the states of the different projects are perceived as their own thing, so I have to add the same state with the same name to the column for each project again. Is there now way to merge workflow states with same names?

Hi 0105401005a0 thanks for sharing your feedback. We understand that this new way of saving a different workflow may be a little "scary". In the next 1-2 quarters, we're hoping to introduce some improvements to the saving experience to give users a little more context and hopefully make it more intuitive. Would love to keep in touch and gather your feedback as we work on improving the UX.

I'm also not seeing this feature. I've created a workflow, added it to a workflow schema (including assigning it to the correct issue type), but see nowhere where I can activate this schema in association with my Project.

If I go to the issue type I'm trying to have a separate workflow for, and click "edit workflow" i see no place to assign it a new one.

EDIT: I have resolved this issue. The next-gen project worfklows aren't created or managed under worfklows at all. You need to create a new one directly from the "Edit Workflow" button that is next to the Issue type under your project settings. It's very scary, but you need to completely manipulate your existing workflow into the new one you want, and then when you hit "Update Workflow" only select the issue type you want that change to apply to. This is NOT very intuitive, as you need to edit a workflow you don't want to change in order to create a new one.

@blim Perfect!  It's exactly what I was looking for.  Thank you for your explanation!  

2a91ce736794 Can you email your Jira instance name (by copying from your URL bar) to me at bryan.lim@atlassian.com? Happy to also help troubleshoot via Zoom call

30b927547d99 When you first go to save a different workflow, you'll need to "split" the workflow from the others after you add your desired statuses and/or transitions. Let me know if that works! See screenshot: 

When I select Edit workflow for my team-managed project for a Subtask item (or any item type to include Epic), it still shows all issue types in the workflow edit screen.

Is there something we need to do to get this change to take effect?

Been following this issue for a long time and while we've all been quite vocal about this and how vital it is however I would be remiss without expressing my thanks for solving this issue. All I need now is parallel sprints working again and I'm all set! haha.

I and I'm sure alot of the undersigned here are very thankful for all your efforts.

Looking forward to Multiple boards as well

f4d118d6d9e0 Let's open a separate ticket for unmapped statuses / backlog statuses so we can more accurately track that piece of work. We're actively working on this now!

Multiple boards: https://jira.atlassian.com/browse/JSWCLOUD-17444 and https://jira.atlassian.com/browse/JSWCLOUD-17371

@blim What about unmapped statuses on next-gen projects? It was listed on this issue but I don't see it yet.

Also, any plans to support any of these other feature on next-gen?

• Be able to setup backlog statuses just like other columns;
• Be able to query issues and tell them apart between backlog and board;
• Be able to set up more boards inside a next-gen project.

Shipped! You can now set a workflow for different issue types (epics, bugs, stories, tasks, etc.) via the workflow editor. Please reach out with feedback.

• • NB: if your instance is on Atlassian Release Tracks, different workflows per issue type is set to be released in the September release

Bryan Lim

Product Manager

"Please separate subtasks workflows from the rest ASAP"

Seconded

Also the ability to add some transition screens when we are moving from one status to another.

Apologies if I've missed a recent update on this but I couldn't see one since early last year. We're desperate to use Post Functions on a next-gen project so that we can automatically update the status of Zendesk tickets that are linked with Jira as per this. Is this functionality likely to appear for next-gen/team projects soon or do we need to migrate the whole project to classic (bearing in mind we've never used classic projects this would be a real pain in the a**).

Please separate subtasks workflows from the rest ASAP

For Team Managed projects, when can we expect individual workflows for the rest of the types?

same for us. 

Same for us @Joshua Selvidge.  Waiting...

It looks like for others with @Monda Slaunwhite issue such as myself, we are still waiting for separate flows per sub type. 

@Jeroen Mares that is exactly the difference, Team-Managed currently only has separate workflows for epics

I have a company-managed project, not sure if there is any difference.(  Edit: I guess that's why )

But I just created 3 flows here : /plugins/servlet/project-config/XXXXPROJECTXXXXX/workflows

1 for Epics, 1 for bugs and 1 for the others.

When activating the flows, I can choose which workflow to link to which issuetype.

screenshot here: https://paste.pics/DBSK5

In the team managed project, I seem to be able to create a workflow for the Epics and a separate workflow for child issue types (Stories, Bugs, Tasks, Spikes) - but I cannot create distinct workflows between the child issue types - in other words, I would like to be able to create one workflow for Stories and a different workflow for Bugs - has anyone else been able to do so or am I missing something ?

Hi @Jeroen Mares,  I don't see the capability to create a separate workflow for each issue type in Jira Team-managed. Any changes I make to the workflow for one issue type (e.g. bugs) affects all the others except Epics, which can be de-selected. 

Do you know if the capability is now there for Jira team-managed projects please?

Many thanks!

@Steffen Schröder it is already available since July 15th. Check out the workflows pages, you can link issue types to the flows.

We are really looking forward to be able to configure different workflows for each ticket type. Can you already share an ETA on when this feature will be rolled out?

Thanks in advance!

Oh Wow. Can't wait.!

@blim has there been any traction on this?

Thanks!

I messed up workflow, can I reset to default or switch to other existing settings as done in standard?

Hey, Any ETA for this?

jeroen10 Yes, thanks for checking in. We're pushing the bug fix to prod today and we're going to QA the experience one last time next week in hopes of beginning rollout in two weeks.

evita.gatpandan et al can you help me fill out this form if you're interested in providing early feedback and getting a sneak peek of what's to come for different workflows per issue type? https://docs.google.com/forms/d/e/1FAIpQLSd7rm6LjOldngKpfhPlRivtVTOZcDxfdwIRGpUXwFOT4pdrsQ/viewform?usp=sf_link

So @blim did you manage to fix that bug? Really could use a different workflow on the epics...

64919750b94b We're trying to fix one final bug which takes away the "start sprint" button when a user saves a different workflow for epics. Hoping to get a fix soon :fingerscrossed:

Any ETA on different workflows for epics? Last note was in the next 2 months on 26/04/21 by Blim

any update on the different workflows per issue type?

I would be happy to test/assist in the Project:

"Ability to unmap statuses from the board".

Currently its hard to have a status where tickets are still in grooming/refinement and not in "ready for dev" (this is our status for first column of sprint).

This makes it very hard for us to identify tickets. Current Workaround is to have all tickets marked as "blocked" in the backlog which are not refined ... so we are missing this flag for real blocker.

Is there a timeline behind this feature/project?

Thanks a lot

Markus

Is there a projected timeline for the development and release of 

3. Different workflows per issue type

?  We eagerly await this feature, and need to plan/postpone certain business processes to align with the availability of this feature. 

Thanks,

Alexander

@blim Thanks for the invitation. While I am not available for the call, I would very much like to participate in early tests, if you have something like a "beta program".

Also, thanks for these improvements. I look forward to being able to use the upcoming features.

Here are more details on my current scenario:

I need to expose our project status to stakeholders outside of the Jira project.

It would be great if Jira supported guest users without taking seats from our plan, then I would be able to set up some filters and boards tailored for these "spectators".

Since guests aren't allowed, I am trying to work around it using Jira Cloud for Sheets, but I bumped on not being able to distinguish issues currently on the board or in the backlog using JQL. This status seems to be controlled only internally by Jira and not exposed as a field. This can be incrementally solved by exposing this field but it would be better to be able to control which statuses belong to the backlog.

Aside from that, I would like to unmap a "NEW"¹ status from our board and backlog to avoid cluttering them with cards yet to be evaluated. This NEW status would only be visible using JQL (filters and sheets).

Even better, it would be awesome to be able to have multiple boards to unmap and group status so we can have a better workflow without adding noise to the dev team board.

I know much of this is possible with Jira company-managed² projects, but they are at the other end of the scale, too clunky and complex. If team-managed/next-gen projects had the aforementioned capabilities, it would be awesome.

P.S.:
¹ Regarding this new status, I would like to be able to set it as the default status for new cards, but this isn't currently possible. I tried to rename the default status, but I can't because the NEW status exists somewhere and I can't delete it, even if it is not currently in use in the workflow. I managed to work around this by renaming and saving in two steps.
² Also, are there any plans to support asking to fill in information when moving an issue in next-gen? I would like to use that to ask why an issue is being moved to the "BLOCKED" state and to facilitate adding details when marking an issue as done.

f4d118d6d9e0 Thanks for the comment, we're currently QA'ing unmapped statuses, would you like to hop on a Zoom call and share how these features would benefit you today + help give us early feedback? Please reach out to me at bryan.lim@atlassian.com if you're interested!

These features would be very valuable:

• Be able to setup backlog statuses just like other columns;
• Be able to have unmapped statuses;
• Be able to query issues and tell them apart between backlog and board;
• Be able to set up more boards inside a next-gen project.

bada6595746b 674bd7954173: Some teams find it valuable to have a simpler workflow for epics. For example, say all stories/tasks need to transition to a "QA" status before transitioning to "Done", epics may not need to go through "QA" before being marked as "Done"

Totally agree with you that different workflows for all issue types provides greater value, but it's a matter of incrementally delivering value to y'all. Releasing different workflows for epics is a natural building block on our way to delivering different workflows per issue type 

Good point, Andreea. The consensus of comments here seem to be in the reverse order: different workflow per issue types. Not sure why workflow needs to differ between epics on a single project.

thanks for the update @blim! 
But why would we want a different workflow for each epic? 

6a09e829031d, 653be79da138, 79c858965e3c: We're working as hard as we can to deliver this as quickly as possible. In the next 2 months, we expect to deliver: 
1. Different workflows per epics
2. Ability to unmap statuses from the board

Soon after that, we will follow up with different workflows per all issue types. Thank you for your patience.

Please release different workflows per issue type asap, our client need it for their multiple workflows progress.

^This! Please release different workflows per issue type soon; I don't think Discovery tickets need to go through Code Review, Sandbox and Staging since no code is being written and I don't want to have to strip out all the rules I have in place to make sure tickets go through the right flows. THANK YOU!

Hello @blim, when we are releasing the feature - Different workflows per issue type?

Hello 3cdd3be98104 thank you for sharing your feedback. Can you please create a feature request for this so we can gather interest?

carina.verdugo886134901 do you also use sprint reports? Here's where we're gathering interest: https://jira.atlassian.com/browse/JSWCLOUD-15106

We have been waiting for the ability to create a "Won't fix" status for a long time. Unfortunately, as I experimented with this, it looks like if you create multiple statuses per column, you are no longer able to create issues into each column (only the TODO column). This is unfortunately a blocker for us, as the board is our main working view and having to drag each created ticket from TODO to where it's supposed to be is too much overhead. I'm hoping this will get solved soon.  

Yes blim! It would be great to investigate the behaviour about starting a new sprint having done issues from the other sprint. Thanks!

That option works for me. Mapping "Won't Do" and "Done" to the same column on the sprint is perfectly fine.

Thanks blim.

36bc20269e4f carina.verdugo886134901 Thanks for the feedback, this is expected behavior.

A board is a representation of each team's work, and we assume work progresses from left to right. Thus, sprints in Jira Software considers the last column on the board as "completed". We recommend you map all the "Done" statuses to the last column on the board if you're running sprints. Here's a link to the documentation: https://support.atlassian.com/jira-software-cloud/docs/assign-statuses-and-edit-columns-in-a-next-gen-project/

Having said that I empathize with your pain here – if you two would like to create a feature request, that would help us gather interest in clarifying this behavior and help us prioritize exploring this problem space a little further. 

For me that happened too, even when we had just one "Done" status: 

"all the tickets in the "Done" column were not automatically removed and got migrated to the next sprint."

I just added a "Won't Do" column as an additional "Done" status. Interestingly, since that column got added to the very right side, all the tickets in the "Done" column were not automatically removed and got migrated to the next sprint. That seems like a bug?

Thank you for the multiple "Done" statuses - this is a HUGE help for my team! Very much looking forward to different workflows by issue type (especially epics & bugs, in our case!) but this solves a lot of the problems we were having. Cheers!

@blim I just sent you the email which I received about this on 3/8/21.  When do you anticipate this will actually be ready for usage?  The screenshot from closing on two years ago still looks like it'd meet our needs.

Good to know Bryan Lim!! Thanks!

borja.campos Different workflows per issue type is our top priority but steps 1 & 2 are pre-requisites . We're hoping to deliver different workflows per issue type in the next 3-6 months. Will keep you & everyone following this ticket updated when we have a beta program up and running!