Improving the Create Issue Experience in Jira Service Management Cloud

60 comments

Drew July 14, 2022

Hi @Jehan Gonsalkorale 

I stumbled across this post, ironically, right after making this community post: https://community.atlassian.com/t5/Jira-questions/Why-are-notifications-not-sent-if-an-issue-does-not-have-a/qaq-p/2079099

If we are not seeing this request type option yet when hitting the "Create" button to make an issue, could that cause customer notifications not to be sent out after creation? The only ways to resolve this problem for our issues is to add a request type in to the issue after it's created, or to use our customer portal to create the issues instead

fishern July 14, 2022

Adding another comment to push the need to have Proforma fields shown through the create button. If your goal is to make the 'create' button the same experience as creating through the user portal this is a no brainer to need to add. Proforma is heavily used on our user portal and we will continue to use that for agents to create until we have support on the agent 'create' button experience. 

Good start....but needs the polish/finish to be considered the best experience for agents. 

Like Jehan Gonsalkorale likes this
Dominik Březina July 14, 2022

Is it just our JSM instance or did Atlassian pull-back this change? Again we have old create issue experience.

I already notified my company about this change and made process updates for agents.

What is going on?

Peter July 15, 2022

I'm seeing the same thing, @Dominik Březina . And as I mentioned in my initial comments here when they made the change, once again there no communication from Atlassian prior to making (in this case reverting) the change. Very frustrating.

Like Chris McCullough likes this
andre.lapointe July 15, 2022

Same here, we are back to seeing the old Create Issue screen.

Jehan Gonsalkorale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 17, 2022

Hi all, apologies for the rollback, we've noticed a bug where fields that are hidden via field configurations in global settings are appearing as required, meaning that tickets cannot be submitted. 

We are working through this bug and are hoping to push the new experience out again today. 

Sorry for the inconvenience, we just could not risk a situation where agents are unable to submit tickets. 

I'll provide an update once this rolls out again. 

Sorry again for the inconvenience, 

 

Jehan 

Todd Thomas July 18, 2022

@Jehan Gonsalkorale 

When rollbacks like this happen, is there somewhere we can go to know it has happened?

Like Kalin U likes this
Jehan Gonsalkorale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 18, 2022

Hi @Todd Thomas

Unfortunately, at this point there is no standard process for us to communicate these things to you, but I definitely agree that something needs to be done. I've flagged this internally and will push for us to find a better solution. 

I can provide an update here and say that we are planning on rolling out the change once again in 24-48 hours once the changes have gone through our standard deployment process. 

Once that happens, the 25% of customers we rolled this feature out to will have that feature once more. We will then slowly roll out to the entire customer base (over the following 1-2 weeks). 

I will provide updates here if there are delays to make sure I provide as much clarity as possible but, as mentioned, will look into how we can provide a more scalable solution. 

Dominik Březina July 18, 2022

@Jehan Gonsalkorale 

After noticing the difference, first I did was checking this article. Editing article by giving it a note at top "Currently we rolled back this feature due to a bug. We expect to roll out this feature again in xxxx" is everything I needed.

Like # people like this
Jehan Gonsalkorale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 19, 2022

@Dominik Březina Great suggestion, updating now :)

Like Dominik Březina likes this
Jehan Gonsalkorale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 21, 2022

Hi all, the update is rolled out again and live with 25% of customers (the same 25% that had access to it before). 

I'll continue to update as we roll out to more tenants. 

Thanks,

Jehan

Stephen Laurin July 22, 2022

I agree with George, a warning would have been very useful, especially for organizations that rely a lot on raising requests on behalf of people.
Because in this case, a large number of request types - hidden from the portal so with almost no fields in the Request Form - were unusable for the agents. Our Service was really degraded for few hours, the time to add the fields back.
Also, a lot of fields moved, which can be very disturbing, especially when speed is a high stake for the agents.
Other than, that, that's a good move to have a more clear delineation between Request Type and Issue type! 

Like marco g likes this
Wendy Thorneloe July 25, 2022

HI

How do we set None as the default? Its actually defaulting to a request type we barely ever use.  Its extra work for us to change it. Can we turn this option off?

Thanks

Wendy

marco g July 26, 2022

hi @Jehan Gonsalkorale 

is it possible to roll back to the old view? our users are experiencing several problems

Jehan Gonsalkorale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 26, 2022

Hi all, many of you have mentioned that you are having problems with the new experience. Please send me an email to jgonsalkorale@atlassian.com and give me an overview of how this is impacting your customers and what would be the preferred behaviour. Please include your instance url so I can disable it temporarily while we figure out how best to fix this for you. 

Best regards,

 

Jehan Gonsalkorale

Product Manager, Jira Service Management

Aaron Clements July 26, 2022

@Wendy Thorneloe Did you find an answer to this ?
Our team also wants to change the default as its currently defaulting to a rarely used request type, and that request type doesn't show a bunch of the fields we need to fill in.

Desmond Cox July 27, 2022

A long overdue change, but unfortunately rolled out in classic Atlassian haphazard fashion with no warning and no consideration for non-standard use cases.

In our instance, we use fields that are only present on the create screen and not on the view/edit screens. These create-only fields are used to populate a Description template via post-function. As a result of this change, these fields all became visible on the agent view which led to much confusion. To resolve the problem, we removed the request type (since 99% of issues were created internally anyway). Now we face another problem since the issue layout cannot be customized without an associated request type.

Like Alan L_ likes this
Jehan Gonsalkorale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 27, 2022

Hi @Desmond Cox

Sorry about the inconvenience we caused you, that was not the intention but what we can do is figure out how we can support you and improve the experience. 

Would you be open to having a chat with us? I'd love to see how we might be able to keep moving in this direction while making things easier for you and other customers with similar challenges. 

If you'd like to book a time to chat with me, please click on this link and we can talk soon: https://calendly.com/jgonsalkorale/feedback-on-global-issue-create-experience-user-testing

I look forward to hearing from you,

 

Jehan

Matthias Fleschütz July 29, 2022

Hi @Jehan Gonsalkorale 

we are appreciating UX improvements and progress in Jira to have a better and more consistent experience for our agents.

Just two comments:

  1. Cascading Request-Type would be more appreciated
    Our team already experienced that the non-cascading request type field is more confusing that it would be if not cascading. Even with just 3 - 4 request types per issue type the list gets quite long and it is not that easy to navigate anymore.
    Additionally it is just confusing to select the issue type and then see other request types again
  2. Un-Improved Experience due to Screen Configs are not affecting agent's view
    At the moment we unfortunately an "un-improved create issue experience", basically because the former "Create Screen" configs are only working on "no request type" choice. That might be by intention, but it has one big disadvantage: Agent's fields in Create Issue screen must be equal to Customer's fields now as there is only one "Request Form" config now.
    That's really a bad thing. Why: agents usually have more knowledge and can enter more information directly when creating issues on-behalf (e.g. by telephone hotline). Users are just less knowledgeable and we don't want to overwelm them with form fields they just dont understand
Like andre.lapointe likes this
Alan L_ July 29, 2022

We got this rollout and I am absolutely livid with it. Before the rollout we were able to customize the agent "Create Button" view using the Request Type fields. This let us make the view a bit cleaner and organize it exactly how we wanted (we do not use the Request Portal, all of our agents make the tickets themselves on behalf of the customers). Now after the update that same customization is gone. Multiple of the fields we use including the Assignee field are auto flagged as "hidden" because they aren't supposed to be viewed on the request portal(which we don't use) and because they are hidden they are forced to the bottom of the display which can not be changed. If you move them around it automatically forces them to the bottom after saving. The only way around this is to flag the request type field as "no request type" so it uses the default layout, but as soon as you go to make another ticket you have to change that again which is incredibly annoying. Also if you have already entered in some information into the fields before you switch to "no request type" it wipes half the fields on the switch and makes you re-enter the data. So the only option I really have for our situation is to fully remove Request Types from the equation so there are not request types and it defaults to No Request type. However if I do that, I lose the ability to customize "Issue view" for the agents once the ticket is created.

 

There are a ton of really good features as part of this update that I do like, but the loss of some of the most critical customization is incredibly disheartening and makes me wonder why so much of the customization is tied to request type but with the intention of customizing the end user portal.

Like Matthias Fleschütz likes this
Jehan Gonsalkorale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 31, 2022

Hi @Alan L_ , 

Really sorry to hear that. Could you please email me at jgonsalkorale@atlassian.com and share your instance's URL so we can turn if off? 

Same goes for anyone else who has been impacted, very keen to help you manage the transition and improve the experience for you. 

Best regards,

 

Jehan

Aaron Clements July 31, 2022

@Jehan Gonsalkorale Does turning off these features cause any roll backs ?
Will any data be lost in doing so ?

Jehan Gonsalkorale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 1, 2022

@Aaron Clements,

That is a good question, but no. Rolling back this flag will not cause any data loss. 

We are currently not rolling the entire feature back, but simply the feature that surfaces the request type configuration in the issue create experience (when a request type is selected). 

This will typically solve the problem for 99% of customers that are having issues. 

Feel free to reach out, more than happy to turn off the feature.

My email is jgonsalkorale@atlassian.com

 

Best regards,

 

Jehan Gonsalkorale

Product Manager, Jira Service Management

Kalin U
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 4, 2022

Hi, everyone. I do see the new experience now but the field labels (from an agent's point of view) are not the ones on the portal. Is that on purpose, @Jehan Gonsalkorale ?

Screenshot.png

Regards,
Kalin

Madhumita Katta August 5, 2022

Hello @Jehan Gonsalkorale 

I really like the fact that the Issue Type and Request Type have been separated. 

However, I am facing an issue in my Jira instance. 

For one particular JSM project, we have only 1 external customer that is using the Portal. We have a required custom field that has been set up to default to a particular value for this customer and hidden from the portal. 

With this change, since the Request Type defaults to the last value, every internal ticket is also getting created with this default value in the custom field.

More than 95% of the tickets are created by internal users. 

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events