Improving the Create Issue Experience in Jira Service Management Cloud

[#1]

Update: This release received strong user feedback. We contacted many of the commenters and are following up with updates that are outlined here. 

Hello everyone! 

We are very excited to announce some much needed changes to the issue create experience in JSM (the blue "create" button) at the top of the screen. 

We have just started to roll out a split select that will encourage agents to select a request type when they create tickets from within JSM. 

Let's have a look at the new experience. 

This new experience has several key differences.

Request type dropdown

You'll first notice that we have split the "Type" dropdown menu into "Issue type" and "Request type". Whenever an issue type is selected, we will select a request type by default. If the issue type does not have any request types mapped to it (such as the "Task" issue), it will default to "None". 

The list is not a cascading select because we know that many of you have a large number of issue types and don't want to force your agents to look through 5 or 10 issue types before finding the request type they're looking for. So, the issue type provides more context about the request type you have selected. We encourage our users to search directly by request type, rather than the issue type. 

Request type layout

You'll also notice that the request type configuration is shown in the issue create experience. You'll only see the fields that are configured for that request type and we will surface all the features of the request type (request type instructions, field help, portal names etc.). Please note that any fields that appear on the issue view only (as in, do not appear on the portal) will need to be configured after the ticket is submitted and will not be shown in the create experience. 

"None" option still available

We spoke to many of you who mentioned that your agents often create tickets without request types to create tickets that do not surface in the portal. These were typically used for internal work. We have ensured that this is still possible while solving the underlying problem. 

These changes will be rolling out over the coming weeks. I'd love to hear your feedback and hope this makes life easier for you and your teams. 

Best regards,

Jehan Gonsalkorale

Product Manager, Jira Service Management

[Dirk Ronsmans]

Hey @Jehan Gonsalkorale 

So if I read this right then an agent will be able to now create a ticket from the agent view as if it were on the portal? Same layout and all?

If so, then I’m really excited! No more jumping back and forth as an agent!

[Jehan Gonsalkorale]

@Dirk Ronsmans essentially yes! The one difference is that they will see fields that are hidden with preset values but they will be prefilled (which we may change later if that suits users better). And yes, no more jumping back and forth, this will be the easiest place for agents to create tickets! 

[Dirk Ronsmans]

Great! 
I’d definitely keep the fields hidden or pre-filled. My preference might be hidden too as those can contain some fields used to guide the process a bit. 

looking forward to playing around with it! Great!Great! Improvement!

It has been one of the main complaints I’ve had from customers that it was really confusing for agents to always jump back and forth. 

side question, will Jira software or work management users also be able to create portal requests thru the create button?

cause then I would definitely hide the hidden fields and those are some of the main people that need to jump between interfaces which is confusing sometimes 

[Mayur Jadhav]

@Jehan Gonsalkorale , Thanks for the update!!

[Jehan Gonsalkorale]

Thanks @Dirk Ronsmans, that is something we will review after launch. That said, those fields will be pre-filled in this roll out, so it will be a good starting place. 

There aren't any plans on enabling the portal for JSW and JWM at this point as far as I'm aware. I think the idea is that use cases that require a portal are served with JSM. But I think the idea of preset values for them might make sense if I'm understanding you correctly. 

It's great to know this will be useful for you! Always keen on making a difference where we can. :) 

[Dirk Ronsmans]

@Jehan Gonsalkorale I might have made my question about JSW a bit too confusing :)

I'm not asking about a portal for a JSW or JWM project but wondering if a user with a JWM or JSW license (who uses the regular Jira interface) wants to create a "request" in the JSM project, will they still need to go to the portal (and thus leave their comfortable interface) or will they also when they hit the create button be able to create that request directly from the Jira interface instead of having to go to the portal?

While typing this I do think that it might be a non-issue considering they probably only will have create permissions in that JSM project thru the portal users role..  Otherwise they most likely have an Agent license anyway.

Having JSW licensed users with Create permissions on a JSM project is a bit odd.. so not sure how that would be covered but I'll figure it out when it gets released :)

Come to think of it, this basically replaces the "Raise a Request" link that existed earlier on :)

[Jehan Gonsalkorale]

@Dirk Ronsmans

I think you're right that this will apply to any tickets created in JSM projects, regardless of the user type. 

I'd definitely appreciate if you could have a play and let me know if it meets all your needs, always keen on feedback. :)

[Amaresh Ray – Multiplier]

@Jehan Gonsalkorale 👋 hope you're well!

Is this compatible with apps that embed an iframe on the portal for a given request type? 

[Jehan Gonsalkorale]

Hi @Amaresh Ray – Multiplier, 

Great to hear from you! I hear things are going very well for you. :) 

This change should not impact apps that are built on the portal, so my first thought is that it won't, but I will double check. 

[Jehan Gonsalkorale]

Hey @Amaresh Ray – Multiplier

I can confirm that this is not compatible with apps for the use case you described. If you describe your use case I can look into how best to solve it, always happy to help!

[Amaresh Ray – Multiplier]

@Jehan Gonsalkorale thanks for looking into this! Our use case is that we embed a form (similar to proforma) for a request type that a customer selects.

Here's an example where we embed a set of apps an end user can request:

 

[Jehan Gonsalkorale]

Thanks @Amaresh Ray – Multiplier, 

That makes sense. I think this will be unaffected because it is in the portal, whereas what we have shipped will only impact the global issue create within Jira projects. So, your app should still be running as expected. :) 

[Amaresh Ray – Multiplier]

@Jehan Gonsalkorale understood, thanks!

Looks like the portal experience will continue to work, but if users try to raise the same request via global issue create that will break since it won't load our app? 

[Dirk Ronsmans]

@Jehan Gonsalkorale ,

to piggyback on to the app question, with the addition of the new (proforma) Forms on the portal now out of the box, will that still work if you use it thru the global create with a request type?

Otherwise I fear it might just be a blank screen :)

[Jehan Gonsalkorale]

Hi @Dirk Ronsmans, 

That is a good question. Unfortunately, we do not have support for ProForma Forms in the issue create experience yet (but it is definitely planned). I can't provide an ETA at this point but I can say that it is a high priority. 

I hope that helps. 

[andre.lapointe]

Question relating to this: is it possible other changes were made or this new feature had other impacts other than just displaying the request type field? When this change happened for us a bunch of our custom fields that were previously not required became required. Also some of the field' positions changed.

Somebody posted a question about this on the community as well, but I think it's relevant to ask here too: is it possible to hide the request type field? We don't use it on our side (we have a one to one relationship between our issue types and request types). 

[Dominik Březina]

Thank you for this article. These seem to be really good changes.

One question: Is there a way to switch positions of Issue Type and Request Type fields? Our agents focus on choosing Request types and aren´t really interested in Issue Type. Having Issue Type as a first option is kind of weird for them.

[Todd Thomas]

This is very exciting news- having to make our agents act like customers has always been an issue.

One of my concerns is with ProForma support. The majority of our requests require ProForma. Based on the past conversations, it sounds like ProForma fields won't appear, correct? If so, this request isn't nearly as helpful (yet) and I'd envision continuing to need to have our agents act like a customer until support lands.

This is absolutely the right direction. Like Dominik just mentioned, though, selecting an Issue Type as the first step may not be the ideal as much as choosing a Request Type, as our agents often complete issues on behalf of customers and don't worry about whether something is an Incident vs Service Request vs etc.

[Peter]

Most organizations I work with wind up having at least the occasional request type that is not meant to be used via the portal, but only for internal use (by the Service Management Team). This change seems to have the side effect of making the internal creation screen show what the portal creation screen shows, such that if we never configured the portal view (because it isn't used and isn't needed), none of the fields show up on the internal create screen either.

This is a confusing user experience and blurs the lines between the screen configuration/internal view and the portal view.  For non-Jira power users, it can already be a confusing distinction, and the way this has been implemented further blurs the lines.

Please consider honoring the internal view and screen configuration for internal request creation as part of this.

[Jehan Gonsalkorale]

Hi @Peter, 

I appreciate your feedback. We are looking to simplify this experience while enabling that use case, which we are well aware of. 

At the moment, you can deselect the request type and get the screen configuration rather than the request type configuration. This is the default behaviour for "Tasks" and the only behaviour for "Subtasks". 

We later plan to enable an issue layout for tasks so that they are configurable at a project level and can be used for this use case. We are looking to move to a world where screens are more intuitive and would ideally like to not surface screens to end users but definitely want to ensure that internal request creation is fully enabled and, eventually, a properly supported feature. 

I hope this is useful and would love to hear any thoughts you have about this. 

[Peter]

Thank you, I really appreciate the thorough and thoughtful response!

First, it would have been nice to see the behavior I described documented and/or advance warning provided. Maybe it was and I missed it, but it blindsided me.  You wrote here:
"You'll also notice that the request type configuration is shown in the issue create experience. You'll only see the fields that are configured for that request type and we will surface all the features of the request type (request type instructions, field help, portal names etc.)"

This does not explicitly state that it's referring to the portal view as opposed to the internal request type configuration.

Second, I really don't think it will be a good idea to start educating Jira users to deselect the request type after spending so much time educating them on what it is and why it's important. Relatedly, as you mentioned, right now we don't have a way to define issue layouts in Service Management projects aside from request type.  Can you imagine trying to explain to users, "deselect request type when you create an issue, but then I've put automation in place that will set the request type afterward. If you remove request type again, you'll lose some of your fields and/or their organization." There's no way.

Third, in my experience, it's not a safe assumption that Tasks will be analogous to internal requests/issues and other issue types will not.  There's too many fringe or crossover cases that, in total, make them more than fringe. If we and the user base had had advance time to prepare and adjust configurations, I could see that working in the long term, but that wasn't the case (or again, if it was, I apologize for missing it) and so this is already feeling fairly chaotic and would only get worse if that assumption is put in place as a default, and not simply an option that can be set per issue type or request type.

Fourth, and maybe most important, there are many cases where the internal creation screen is intentionally different than the portal request screen, for the same request type in the same project. It seems that this removes the ability to have a request type available in both places (portal and internal), yet offer more fields internally.

[Jehan Gonsalkorale]

Hi @Peter

Not a problem at all, I appreciate your carefully thought out reply. :) 

I'll respond to each separately. 

1. Two very good points. I've updated this page but do agree that we could have communicated this change with more warning. I'll look into how we can do this so changes don't arrive so unexpectedly. 
2. Your point on deselecting request types is very much understood. We opted to choose this route to avoid a big bang release where we surfaced issue layouts and request types all at once as this would take us many months more work and that kind of big release would have more bugs. That said, we probably could do better to show the direction we are going in and bring our customers along the journey. 
3. Sorry, when I referred to the "Task" issue type, that was just an example that we create out of the box. I definitely do agree that any issue type could be used for internal work and would need to be able to have an issue layout configured for it. 
4. Thanks for this feedback. This was the subject of substantial internal discussion and customer conversations as we went through the discovery process. We generally heard that users wanted the end user and agent create experiences to be the same, but our user base is so large that this is definitely not always the case. I'll talk to the team and will see if there is a way to solve for this, I suspect there may be some options. 

Very sorry about the inconveniences here, but I do appreciate the feedback, it will be taken on and I'll be making every effort to make sure we notify users before changes to these kinds of core experiences are released and will work on making the documentation clearer, both about the intended behaviour and where we are headed. 

[Jehan Gonsalkorale]

@Hi @Peter, 

I may have found a workaround for you in the meantime. You can set fields to be "Hidden" and set preset values for them to be autofilled. This same functionality can be used for agent-only fields if you don't set a preset value. They will appear to agents in the create experience but not in the portal. 

Could you let me know if this works for you? I tested this with a number of fields and it seems to work. 

Let me know what you think. 

[Peter]

Hi @Jehan Gonsalkorale 

Yes, that does seem to work, thank you for the workaround. I think it achieves the goal but it does add another configuration step and  slightly more complexity.  I appreciate you investigating and providing a workaround, though. 

I understand what you're saying about trying to avoid a "big bang" release that potentially contains more bugs; even though I would have preferred more of the functionality available to support such a change, I see your point there's no perfect answer here.  Thank you again for reading, responding, and taking on the feedback.

[George]

This update removed some of our custom fields from the portal view. We only found out when our agent complained that they couldn't find the fields. Anyone else had the same problem?