Change the workflow (or issue type) of a request type in Jira Service Management

[#1]

Hi all,

We recently launched a new feature that allows you to change the workflow (or issue type) of a request type. 

How does it work? 

This feature lets you change the underlying configuration of a request type so that the workflow (and issue type) can be changed. We handle all the screens and schemes and make sure that it just works for you. 

You simply click on the three dot menu and select the "Replace workflow" option. 

You are then taken to this screen. 

You then select the workflow.

And can select your preferred issue type if multiple are mapped to the same workflow. 

After that, if you have any statuses that are missing from the new workflow, you will have to map them. 

After that, all that's left is for us to update your existing issues. 

And that's it! It can take as few as 30 seconds. Have you used this feature? If so, we'd love to hear from you in the comment section below. 

Best regards,

Jehan Gonsalkorale

Product Manager, Jira Service Management Cloud

[__ Jimi Wikman]

Looks interesting.

I'll sign up and test it out :)

[Jehan Gonsalkorale]

@__ Jimi Wikman I saw that you signed up, you'll be given access in the coming days. We will be waiting for your feedback. :) 

[Patrik Korovsky]

Hello @Jehan Gonsalkorale

What is the use case please? Does it mean that you can specify workflows individually for requests? This means that even if they share the same issue type, they can all have different workflows?

Thank you

[Haddon Fisher]

Is there any documentation on how this will work? Seems somewhat counterintuitive and potentially incredibly confusing to break the relationship between workflows and issuetypes.

Seems like maybe giving people the ability to move request types to a new issuetype would be better...it's both something people have been requesting for a long time AND doesn't break UX.

If not, then perhaps could we as admins disable this functionality? Feel like we don't need any more help making this complex 🤣

[Jehan Gonsalkorale]

Hi @Haddon Fisher and @Patrik Korovsky

I can provide some clarity here, this feature simply allows you to change the issue type of a request type. 

The only difference is that we are encouraging users to think about issue types as being synonymous with workflows. We are introducing a new feature this year that allows you to access any field on your instance within the request type configuration of the project (while adding the field to screens under the hood on your behalf), most customers will not need to think about screens anymore (unless they want to).

This makes issue types less relevant when configuring fields in request types. 

We are certainly aware that some users use field configurations and contexts at the issue type level or use issue types for reporting, but we are moving to a world where issue types become a less relevant to most users. 

That said, what we are not doing is making changes to how Jira actually works. We absolutely don't want to make sweeping changes. 

So, this new feature allows you to select a workflow within your project (but later will allow you to select any workflow on your instance) and map your request type to it (via its associated issue type). 

And it does allow you to simply change the issue type, if that's what you need to do. 

It essentially replicates what you would do now but takes care of the tedious tasks under the hood so you don't have to. 

Please sign up for early access, we'd love to get your feedback.

Best regards,

Jehan

[__ Jimi Wikman]

@Jehan GonsalkoraleI like this change a lot!

The way it shows the changes is excellent and I think this is something that should be added in other products as well.

I will write an article about it with some thoughts on in it in more detail.

In short: This is a great way to manage a switch of workflows and issue types.

[Jehan Gonsalkorale]

Thanks so much @__ Jimi Wikman

I really appreciate the kind words, I'll share it with the team. 

[Rubén Álvarez González]

I have a question, is this feature in Administration area or in projects configuration?

[Trevor Dearham]

Thank you @Jehan Gonsalkorale for your explanation. I'm still a bit confused about what this is doing. Is it simply like using the Move function to move a single issue to the same project with a different issue type, but applied to Jira Service Management?

The 4 open issues screenshot appears to be saying that this change action is affecting all the issues of the same time, rather than just the current issue.

[Haddon Fisher]

Hi @Jehan Gonsalkorale - I understand the inclination to make some improvements to the way configurations are built; the current model is complicated and takes some getting used to.

However I think what I am hearing you say is "we absolutely don't want to make any big sweeping changes to how Jira works, we just want to move to a world without screens and field schemes and issuetypes." To me, those sound like not-small changes :)

1) Recent and much smaller changes (I am specifically thinking about "issue layout" and "epic link") have been done at a glacial pace, which is leaving us stuck in a multi-year limbo waiting for this or that feature to be enhanced to support the new model. Atlassian also has a bit of a habit (not that they're unique here) of rolling out something minimally useful and then walking away, leaving people stuck again, but in a different way. Can you talk a bit about how these bigger and significantly more important changes will be rolled out to avoid that?

2) You called out above that "We are certainly aware that some users use field configurations and contexts at the issue type level or use issue types for reporting, but we are moving to a world where issue types become a less relevant to most users." Does this mean you are eliminating the ability to have multiple contexts and required fields on a per-issuetype-per-project basis either temporality or long-term? I think people would have something to say about this :)

3) As I said above, a lot of these models have been in place for a LONG time, and while they could definitely use some TLC, they do work pretty well. Can you talk about why Atlassian is choosing break these models entirely instead of, for example, just giving people the ability to change the issuetype on a request type? From an outsider's perspective, it would seem both more challenging to do it this way and also rachet up people's confusion and frustration with a tool that is already escalating quickly in these categories.

[Jehan Gonsalkorale]

Hi @Haddon Fisher,

I may have not have expressed myself very well here, apologies. Re-reading my reply, I definitely was not very clear. 

We are not removing screens and schemes and issue types in the foreseen future, we are simply removing them from the mental model of less experienced users. If I can compare to Microsoft Excel, novice users are unaware of VBA but advanced users are very much aware and that makes the tool more powerful for them without adding additional complexity to basic users. 

This is essentially how we are approaching this. 

1. It might be worth having a chat to cover the examples you provided here. I think I know which specific issues you mean, but want to make sure I understand them properly. Even if it's not in my direct remit, I'd be more than happy to pass it on and make sure it gets to the right teams. You can email me at jgonsalkorale@atlassian.com 
2. The idea here is simply that basic users shouldn't need to understand issue types, screens, screen schemes, field configurations and contexts. We are definitely not removing any of this functionality, simply providing a path for basic users to not have to understand these concepts to create a service desk (or software project). The future state will be one where you can drag and drop any field on your instance from the right hand panel in the request type configuration and we will update screens under the hood on your behalf. We will continue to respect contexts and field configurations, so any fields that are suppressed will not be available. As for contexts, each field can only have one context per project, although the UI does suggest that you can create multiple per project. But this has always been the case. 
3. Totally understand you and we actually agree. The new feature lets you change the workflow of a request type by changing the issue type. We are encouraging people to focus on workflows as that is simpler, but Jira works exactly the same way it always has. We essentially change the issue type to the one that is mapped to the desired workflow and let you choose the issue type you want if there are multiple associated with that workflow. It is no different from deleting your request type, recreating it on the issue type you want and then bulk moving your tickets to the new issue type and request type. We will later let you select workflows outside the project but will, once again, indicate the issue type we will be adding to the issue type scheme and will provide documentation on the changes we will make to the issue type screen scheme and workflow scheme to make the new mapping work. 

I'd love for you to sign up for this EAP program (see link on this post) and test this out on a demo project so you can see how it works and, more importantly, tell us what you think. You can also sign up for another EAP program where we'll enable all fields on your instance on the right hand panel within the request type configuration UI. You can sign up for that here. 

We have spoken to many advanced admins and have gone to great lengths to make sure that they don't lose the power that the Jira data model gives them. We'd love to get your eyes on it to get your feedback to make sure it meets your needs. 

Let me know if this answers your questions, very keen to talk to you further!

Best regards,

Jehan

[__ Jimi Wikman]

If anyone wants to see what it looks like, I have added a video for this here:
https://www.youtube.com/watch?v=Ityesw-TgYg

[Haddon Fisher]

Hey @Jehan Gonsalkorale first, thanks for that long and detailed response! Atlassian's engagement with users has really undergone a sea change in the last year or so and I am HERE for it. I'm going to sign up for all of the early access I can and I'll send you feedback. However there is one question I would love an answer to publicly in this forum:

You say "We are not removing screens and schemes and issue types in the foreseen future, we are simply removing them from the mental model of less experienced users" and then go on later to say "The idea here is simply that basic users shouldn't need to understand issue types, screens, screen schemes, field configurations and contexts. We are definitely not removing any of this functionality, simply providing a path for basic users to not have to understand these concepts to create a service desk (or software project)." 

It seems your fundamental premise is that a user of any experience should be able to engage with this functionality. Can you talk a little about why you're optimizing for that? I totally get the aspiration of "we want this to be so simple, anyone can do it!"...but I've seen instances where "anyone can do anything" and very politely, it is not something anyone should be aiming for 😂 

Again, I think there's TONS of room for improvement in all of these areas - off the top of my head, field schemes and screens for example seem like a great target for some flattening. However, the idea that we should be lowering the bar for admins instead of making life easier for people who already have the expertise (and have been suffering for years) seems (to me) to be less than optimal.

[Jehan Gonsalkorale]

Hi @Rubén Álvarez González ,

This feature will be available in "Project Settings" > "Request Types" within the project itself. 

Please sign up and let us know what you think!

Best regards,

Jehan

[Jehan Gonsalkorale]

Hi @__ Jimi Wikman

That video was amazing! Thanks so much for taking the time to make our day. :) 

I shared it with the team and they loved it!

[Jehan Gonsalkorale]

Thanks @Haddon Fisher

That's great to hear. We should be engaging very closely with you all, that's why we're here!

I totally understand your point here. What we don't want to do is change how Jira works in ways that break things. Our goal is to make it possible for new admins to create a viable service catalog. That means they need to be able to create their request types, ensure they are mapped to the right workflows and are discoverable in the portal. 

So, the happy path we are trying to create is one where admins with no Jira experience can get the basics done. The idea is that we provide clear information and sensible defaults so that these activities don't allow admins to break things or create a messy configuration that later slows them down. 

The idea is not to let anyone do anything but just let them get the key tasks done with some basic guardrails in place. 

As for the use cases you mentioned, there is a team working on flattening screens and making the "Issues" configuration pages more user friendly and more powerful. So, this is definitely something that we are doing, but the amount of work is not trivial so it will take some time. 

Thanks again for the good discussion, your thoughts here likely echoed by many others, so glad to be able to talk these through. 

Thanks,

Jehan

[Jehan Gonsalkorale]

Hi @Trevor Dearham ,

That's a good question. This change updates the request type and changes the underlying issue type. This means that, if you have any existing issues, whether open or closed, we will need to move those issues to the new issue type. 

So, this is not done from a single issue but for a request type and all its associated issues. 

Does this answer your question? Apologies if I've misunderstood. 

Best regards,

Jehan

[__ Jimi Wikman]

@Jehan GonsalkoraleI am glad you liked it and that the team found it useful as well :)

Keep up the awesome work and have a great weekend!

[Joerg]

I just signed up with one of our instances, as this feature will spare me a lot of additional manual work. :)

Hope this makes it to all instances soon.

[Muhammad Akram Sharifi]

I like it for the purpose of moving request types from one issue type to another 

I am glad now its available. 

[Cao Elanc]

Thanks for this capability. This is manual operation. 

Is it possible to update the issue type from a workflow transition (keeping cautious about status coherency between wrokflows), to make it transparent to the user.

Objective is to ensure coherency of the issue type with issue content, and get it transparently done by the first steps of the workflow.

[AnamEjaz]

Thanks for sharing but what if we need same possibility for Jira Software projects? @Jehan Gonsalkorale @__ Jimi Wikman 

[Deleted user]

-

[YY Brother]

Hi,

May I know if we can use two different workflows for different request types combined with the same issue type in a JSM project?

Thanks

YY哥