How we’re addressing your feedback on the issue create experience in Jira Service Management

[#1]

Hello everyone,

This is Jehan from Jira Service Management with a follow up to an issue create release that we had begun rolling out. While the majority of you provided overwhelmingly positive feedback, we did hear back from many of you that these changes made some experiences worse.

We take your feedback very seriously and have since paused our rollout to ensure we didn’t cause these unintended issues for any more customers than we already had.

In this article, I’ll first go over what was included in the rollout and the feedback we received, and what’s coming next to address your feedback and enhance the issue create experience.

What was included in the feature release

Recently, we had started rolling out the following updates to the issue create screen:

1. Added a request type drop down to address the pain point of tickets being created without being mapped to request types.
   
   
   
   

2. Surfaced the request type configuration after a user selects a request type, so internal users get the same experience as end users on the portal.

While we helped fix the pain points of ensuring a request type is selected (where appropriate) and surfacing the request type configuration, there were four general themes of feedback detailing unintended consequences:

1. Change management: Many of you, quite reasonably, were looking for better communication of the changes given how critical issue creation in Jira is to most teams so they could inform their teams.

2. Incompatibility with Forms: As this new experience only shows what was configured on a request type, issues that were built entirely on forms were missing fields from forms.

3. Specific agent create experiences: We learned that many of you configured the underlying issue type configuration to provide a bespoke create experience for agents. Our release meant that agents were seeing the same experience as end users. 

4. Tabs: More experienced users that use tabs found the new experience broke tabs for issue creation within Jira.

So, what are we doing now?

As a first step, we are releasing a toggle in the issue create screen that lets your agents decide whether they prefer to see the request type configuration or the underlying Jira configuration. This way, we still satisfy the majority of use cases where the request type configuration is preferred, while providing an easy opt-out experience for those of you who need the issue type configuration.

When an end user deselects the “Use request type fields” option, it will appear as if a request type has not been selected and that selection will persist for that individual user.

This new feature is compatible with the “Show fields” > “Custom fields” functionality that lets end users customise which fields appear on the issue create experience.

This new feature will be going live over the coming weeks and you will soon see an in-app notification informing you of these changes.

And what’s coming next?

This fix will allow us to roll out the new experience out to all of you while ensuring it meets your needs. That said, the toggle is a temporary fix. We are looking to make improvements over the next year that will make Jira Service Management even simpler to configure while retaining the same powerful capabilities.

In the next 12 months, we will be looking into the following enhancements to the the issue create experience:

1. Full compatibility with Forms: We know that those of you using Forms need them to work with the create issue experience.

2. Agent-only fields: We know that many of you want the ability to create different issue create experiences for agents and help seekers. We will be looking into this.

3. Tabs: While we can’t promise to fully support tabs, we will look into how we might be able to solve this so agents can create issues with some level of pagination.

What do we want from you?

We would love to hear from you. If you would like access to the new toggle feature right now or would like to leave us feedback, please click on this link to start a conversation. Alternatively, feel free to start a conversation right here on Community by leaving a comment.

Thank you again for your patience and for your feedback that plays a huge role in the product development.

Best regards,

Jehan Gonsalkorale

Product Manager, Jira Service Management

[Tobias H]

Not sure we will be needing this, but can definitely see bigger organizations having explicit usecases.
Great initiative with the easy switch option!

[Marini Marini]

When your JSM portal customers are the internal staffs that have access to JSW or JWM and thus have access to Jira, we definitely need this feature. In our case, we have to purposely take away the Create Issue permission for all users including agents in almost all our JSM projects. However, we keep on receiving a warning from Jira saying that there is a configuration issue i.e. users do not have Create Issue permission which is quite annoying.

We can't wait for this new feature to be rolled out to our site.

[Adam Kassoff]

Having the forms on the create issue screen would be very useful as a majority of my "customers" are internal users that also have Jira licenses. 
If they create an issue not using the portal and select the request type several fields are left off because of the forms that were used. 

[Greg D]

This change does allow for a consistent experience, but it was easy enough to force our users to go into the portal using the "Raise a request" on the left-hand side panel.  Just like @Marini Marini in the majority of projects, we only allow the Service Project Customer - Portal Access to create issues and that stops the internal users if they try to use the create button at the top (that project will not be in the dropdown of available options).

But along the lines of what Marini described, the recommended permissions for Jira Service Management project are not ideal.  We deal with this in every one of our projects for every Project Admin:

In the majority of scenarios we do not want all internal agents creating issues within the project itself (like I described) and we also do not want them deleting emails that they sent out to customers.  There are some time where we need to open this up to let them remove sensitive information, but we typically reserve these functions for advanced users (a different project role).

Are you able to stop these errors from showing in the projects?  I always click "Ignore errors" and then it will not show again for just me unless the permission scheme is altered... but that does nothing fo the other Project Admins and if they are less experienced they may accidentally click "Fix permission" which spins up a new scheme and causes problems with our desired setup.

[Asher Francis]

Can we have a setting, per project, to choose which is the default view when creating issues? We have some projects where we'll want agents to create using the request type, and other where they'll want to create using the issue type

It's not ideal for users to have to change the toggle every time they create an issue, so we should be able to choose a default setting for each project

[Dan W]

Being able to set a default request type would be nice as well.  It appears to be sorting them alphabetically, and the request used most often is nowhere near the top of the list.  Being able to type the name helps but setting  a default per project would be better.

[Allison Stewart]

Excited for this release.  

We'd like to use FORMS throughout our JSM but without the ability to upload attachments, Forms are useless to us.  When you're implementing the full integration of Forms, please consider that.

[Mike Bowen]

Looking forward to this release; some of those features are exactly what we have wanted for a while. Thank you. 

[Nadia]

There are still issues with the new create issue screen - any fields mandatory in the request type are not considered as mandatory, more over any fields mandatory on the field configuration getting skipped as well. Can you please fix that as well - it will be very much appreciated! Just for case, the bug for that was already created and sits in Atlassian backlog. 

[Hubert Bedyk]

Does this new feature have any impact on the Customer Portal and how do CP users see request types? Can you confirm that?

[James Wicks]

Hi Hubert,

On the portal, customer's will only see request types that are in your project. Portal user's typically do not have a Jira license, which effectively means Portal customer's will not see any of your issue types.

For example, you project may be set up with only one issue type called "Incident", however, using the request types, you can break those incidents down into something that the portal users can understand. Software vs Hardware. You can have 2 request types on your portal which allows a customer to select if it is a hardware incident or a software incident. These 2 incidents are captured as a "incident issue type" in your project.

So basically, in your project settings, under request types, any request type that you have added and is not under the hide from portal, will display on your portal. These request types can also be grouped using the functionality provided. So your CP users can log in, and view different requests groups to make their experience better.

Example of groups -> in your portal you can categorise your request types into groups, if your desk deals with incidents and service requests, you would typically setup your portal so that user initially sees 2 groups - Incident and Service Request -> when they click on the Incident Group, it will display the incident type of requests that they can raise, eg: hardware vs software. If they click on the Service Request group, they will see your service requests types that you have setup, eg: New laptop request, account creation, (pretty much whatever your department provides as a service.)

In simple plain terms, your issue type can be considered your main category, you can use the request types to break down those categories into sub categories. So come month end, for example, you can report that 20 incidents have come through your desk in the last month (These are your issue types), but then you can also report that out of 20 incidents, 10 were for hardware related things and 10 were for software related things (These are your request types)

Apologise for the long explanation, I really did try and simplify this as much as I could.

J

[James Wicks]

Hi Nadia,

The request type functionality (ie: required fields) set up on the request type screen is only applicable to the portal functionality.

I do 100% see where you are coming from a admin point of view, however you can actually implement this so the mandatory fields are applicable for agents when logging a request from inside of Jira.

How I have overcome this is by implementing Field Required Validator on the workflow on the create transition. So all the required fields that are needed on an issue create screen on stipulated under that validator.

The cons to this are, if you have one screen used for incidents and service requests and one workflow as well, you cannot unlike on the request screen split your fields which only used for incidents apart from fields which are only used for service requests. 

To circumvent the con above, I intend to build a "smart workflow". What I mean by this, is basically before an agent can move the ticket into a "In Progress" type of state, we make a screen pop up, they can only move the ticket into "In Progress" if all the fields are filled, otherwise it returns an error to the user stating they need to fill in the fields. So basically, if the ticket comes into Jira, and lets say for example there is only incidents and service requests, the ticket is already classified as one of the 2. From your initial status, "Open" I would 2 have transitions into the "In Progress" status, one for incidents and one for service requests. On these 2 transitions from "Open" to "In Progress", I would include conditions on each, I would use the Value Field condition. Basically the conditions would force the user to select the right screen to pop up and fill in the data required for incidents or service requests. Obviously I would have a separate "Classification Screen" for incidents and service requests. The nice thing is, the user doesn't see 2 separate transitions when changing the status to "In Progress", because the conditions in the workflow are hiding one of the transitions based off the ticket being a service request or incident.

I have implemented this in many organisations because tickets were being closed without all the necessary fields being filled in. The best approach is to use a "Smart" workflow and pop up screens that dictates to the user what must be fields must be provided in certain scenarios. This makes the user experience a lot better as they can go through the workflow only needing to fill in the fields that are needed and provides better reporting as you won't get junk data.

Hope this helps.

J

[Nadia]

Hi @James Wicks thanks for the detailed explanation and just to confirm - we do understand how it works.

The issue is though - even if you have fields required in the field configuration scheme for the issue type connected to the request type, you still can proceed with empty required fields and create the issue from internal Jira create screen - this is really a bug in our opinion and that's what I was referring to. 

All the details were already shared with Atlassian, and we just hope that can be fixed soon. 

Right now, users can create issues from internal Jira create screen in JSM project, even if fields are required in the field configuration. 

[Jehan Gonsalkorale]

Hi G, 

Thanks for your comment. I wasn't aware of that permissions issue until you flagged it. I then promptly heard the same thing from several Atlassian partners, so I escalated this internally. I'm talking to the team about whether we can update that permissions feature so that users who customise JSM permissions are not given annoying error messages. 

I'll provide an update once I hear back. 

Best regards,

Jehan Gonsalkorale

Product Manager, Jira Service Management

[Jehan Gonsalkorale]

Hi @Nadia

Thanks for taking the time to comment. This is a known bug and it is something we are looking to fix. 

I'll provide an update once I get a timeline for a fix. 

I hope this helps, we are definitely looking to keep improving the create issue experience.

Best regards,

Jehan

[Jehan Gonsalkorale]

Hi @Allison Stewart

Thanks for your feedback, it's appreciated! And sorry for the delayed response. 

I can confirm that there are teams working on adding attachments to Forms but cannot provide a timeline on that yet. 

I'll ask that team for a timeline and will get back to you. 

Best regards,

Jehan

[Jehan Gonsalkorale]

Hi Dan,

That's a very good point. We will be making updates to include ProForma Forms in the issue create experience and will consider that use case when we start designing the new experience. 

I'll provide an update in a few months once we are exploring options. 

Thanks,

Jehan

[Jehan Gonsalkorale]

Hi @Asher Francis ,

Thanks for your feedback. This is a temporary state while we do the work to provide a more permanent solution. 

The feature will remember whether the user last selected the request type configuration or underlying screen configuration. So, that will let them avoid having to select it every time. 

We will be updating this experience later and would love to talk to you to understand your needs so they are top of mind when we design the new experience. 

Best regards,

Jehan

[Ricardo.Gomes]

I think the problem with the release of this feature was to turn it "on" by default, which caused some of our projects to break and had lots of internal users complaining the create form was broken.

In our use cases, we don't want to see the same fields from the portal on the internal view. That's why they have different configuration options such as fields that can be seen, different behaviors as far as validation, required/not required, etc. It was all carefully thought out and this just broke everything because it was turned on by default and users didn't realize they had to turn it off.

[maurice.hardy]

Yes by default having this feature turn-on caused some our IVR to experience some issues. Please turn this off by default and implements an option under the Request Types for Admins to activate this if they want to use it. 

[Peter]

Same here. The default "on" means that by default this causes the same "breakage" that the initial rollout of this feature did.  99% of Jira users don't understand what the toggle means, if they notice it at all.

[Chris Uggen]

While having the customer request type on the create screen is nice, it doesn't fully answer the original requested change in https://jira.atlassian.com/browse/JSDCLOUD-1211.  This request was for the customer request type to appear on the Edit and Create screen.  As of now, I cannot added it to the Edit Screen.

Additionally and more importantly, we receive most of our issues via email.  The email channel assigns a static customer request type that needs to be updated when the ticket is worked.  This is a failure point because people forget to edit that field and since the default email customer request type is valid, the issue will save with a bad value.  I've tried to add a validation to the workflow, but there are no options and since the customer request type is not on the edit screen, it makes it even more difficult to catch.

I'd love to know how this scenario can be addressed. 

Thanks - CU

[Jan Odvárka]

Hi,

untill the create issue button will be absolutely same as it is on customer portal it is not usable due to automatizations, passive default fields under specific request types.

Easy solution - please enable to use create button to forward user to customer portal. Just let us add url under this button and we will be so happy.

Kind regards 

Jan 

[Yatish Madhav]

Thanks for this post @Jehan Gonsalkorale  - it really help resolve an issue for us! 

I went through all the comments and didnt realise this was so much of an issue for some users. I hope there is resolvement for them :) I only just found out about this so might prematurely love it but will look out for any issues we face, if at all.

FYi the 2 paragraphs starting with "When an end user deselects..." is duplicated above :)

[Yatish Madhav]

I guess what I was not sure of is that it is toggled on by default. I guess I agree that it should be configurable to per project AND also should cater for the required/non-required configrations.

Thank you again