We are making request types easier to configure on Jira Service Management Cloud

[#1]

Hi everyone,

We are excited to announce that we are making some improvements to request types to make them better suit your needs.

All fields for Jira admins

We just released the new field panel that gives you access to all the fields on your instance on the right hand panel. This means that you no longer need to modify screens to add fields to request types. When you add a custom field to a request type, we’ll add it to the underlying screens as needed. When a field is added to either the request form or the issue view, we will make sure the field is added to all underlying screens.

The field panel only shows recently created fields and those associated with your project by default but searching reveals all the fields on your instance. 

This makes new custom field creation much easier: simply create the field, navigate back to your request type and refresh the page. The new field will appear on the right-hand panel.

Issue view fields just got simpler

The issue view contains all fields on the screen by default. We understand this isn’t ideal as request types often share screens, meaning that adding fields to one request type causes fields to appear in others in the issue view.

We are changing this behaviour so that, other than some default fields (such as SLAs, Satisfaction, Assignee, Reporter etc.), only fields explicitly added to the issue view will be visible on the issue view.

How will this impact your current configurations? It won’t. These changes will only impact new request types and any fields added to screens from now on (the fields will no longer appear unless deliberately added). Existing request types will not change.

This means that you will be able to modify your request types by dragging and dropping the custom fields you need without any of these changes impacting other request types.

When can you expect these changes? We will be rolling them out this quarter. 

What’s next?

We are working on a number of exciting initiatives to make life easier for Jira Service Management admins so you can get started faster.

Feature	Description	Expected Release
All fields for team-managed projects	Custom fields (including asset fields) from company-managed projects will become available in team-managed projects.	Q1 2023
Forms attachments	We are working on an attachment field for Forms that will enable you to configure Forms with attachments at the bottom.	Q2 2023
Forms in issue create	We are working on bringing Forms to the issue create experience.	Q3 2023
Request type templates	Request type templates that you can create on demand.	Q3 2023
Workflow templates	Workflow templates that you can create on demand and map to any request type.	Q3 2023

[Matthias Ortner]

Very nice! Also looking forward to attachments in forms 😊

 do you know when adding pictures to forms will get out of beta?

[Simon H]

@Matthias Ortner I'm looking forward to shipping attachments too. 

As for images - we implemented a cheap-n-cheerful solution in the old ProForma marketplace app (it's still there in the DC app), which allowed you to paste a URL to an image hosted somewhere else, and it would display in the form. This was more of a hack than a real solution, so we pulled it out of the cloud implementation. I don't have an ETA on when it is coming back, but it is related to attachments, and I know the team are discussing it.

[John Funk]

Really good stuff coming!

[Mikel Whipple]

Looking forward to attachments but any word on when we can restrict ticket creation in a request to certain people or roles? 

[Sarah O'Halloran]

@Simon H Are you still managing https://jira.atlassian.com/browse/JSDCLOUD-10707 ?  There have been many requests for updates with no response and this updated timeline would be appreciated.

[Suzi Firth]

This is a great improvement. The amount of time I spent when building our Jira website trying to figure out why my field wasn't showing. This will save a lot of time.

[Jehan Gonsalkorale]

Hi @Mikel Whipple, unfortunately we won't be looking at that in the near term but we are very aware that this is a valid user need. 

The reason for this is that we are focusing on making Jira Service Management easier to use and, once we've made key improvements on the user experience, will look to add functionality like this. 

Sorry I can't provide better news, I know that this is very important functionality. 

I hope that helps and provides some context as to why we can't prioritise it (it would not be a trivial effort).  

[Jehan Gonsalkorale]

Hi @Sarah, I mentioned in the article that Form Attachments are coming next quarter. Does this answer your question? 

All good if you missed it, keen to understand if you were talking about something different or needed more info. :)  

[Jehan Gonsalkorale]

Thanks @Suzi Firth

Really appreciate the kind words, glad to hear that it is making your life easier! :) 

[Sarah O'Halloran]

Thanks @Jehan Gonsalkorale that's great, it was just a reference to the original suggestion thread as many watchers have been asking for an update there and it still says Q4 2022.  Would be great to know who the best contact is for updates in future, so that we can communicate that to our stakeholders.

[Jehan Gonsalkorale]

Gotcha, thanks for clarifying @Sarah O'Halloran. 

That would be my colleague @Simon H, so feel free to list him as the best contact.  

This work is in progress so we are fairly confident that we will get it done this financial year. :)   

[Sarah O'Halloran]

Fantastic, super excited to see this rolled out, thanks @Jehan Gonsalkorale !

[Peter]

Is anyone else noticing that the field order as presented on the screen configuration is getting automatically altered in the background? The timing of this happening seems to coincide with the release of this functionality.

While I recognize that with the Request Type configuration, it is not strictly necessary to organize the fields on the Screen configuration, it was helpful when the request types more or less followed and honored this order, and it also made it easier to find fields on screens which comprise many fields.

[Jehan Gonsalkorale]

Hi @Peter, 

This will have changed as we now surface all fields associated with that project on the right hand panel (rather than the fields on the associated screen). 

This does mean that the screen will only be used to identify if the field is used in that project (essentially capturing all the fields associated with at least one screen associated with the underlying issue type screen scheme). 

This will present some challenges to customers that used screens but we hope these changes are still a net positive for all users. 

This brings me to the question: what was the benefit of surfacing the order of the screen? 

We may be able to make updates that solve this problem without using screens per se. 

Looking forward to hearing your thoughts!

[Peter]

@Jehan Gonsalkoralethanks as always for your response and query.

Right now, the experience is kind of chaotic, to be honest. Here's the combination of behaviors we're dealing with:

• field availability is specified on screens, which are specified per issue type, not per project
• fields can be ordered on the screens
• field order as specified on the screen matters/is honored in some cases, such as issue creation, but now not in other cases
• field order can also be specified in the issue view layout in both SM and Software projects
• although fields as made available per screen, and screens are per-issue type, availability in the issue view layout is per-project
• in the past, the issue view layout seemed to start by roughly honoring how fields were organized on the screen. Now, it actively DISorganizes those fields as viewed on the screen

So, I've got multiple places to configure my field availability and organization, and there's overlap and sometimes conflict between how they behave.  To be honest, as things are now, there are still times when the field order gets disturbed from what I've set and I'm not completely sure why.

Honoring or at least not messing with field organization on the screen itself was useful for three main reasons that I can think of:

1. If you have a lot of fields on the screen, having them organized in a logical way helps to find and administer them rather than having to scan a long list or control-F for everything
2. Starting out by following the field order on the screen makes configuring the issue view layout quicker
3. If you are sharing the screen across multiple projects, and the request types or issue type view layout honors the screen ordering, you don't have to completely fix/arrange the fields on every single request type/issue type which use the screen

This experience is in a very weird and not admin-friendly limbo state of how screens and field organizations are handled.

[Peter]

@Jehan Gonsalkoralefurther confusing the matter, I just received the following messages when applying a new issue layout in a Jira Software project:

"the field order and issue layout won't be shared", followed immediately below in the same notification by "your changes will affect the following projects" with a list of the three projects sharing that view screen. How can both of those things be true at the same time??

[Jehan Gonsalkorale]

Hi @Peter,

Thanks for the constructive and detailed response. 

I understand that this is causing you challenges and can see why. The reason why we made these changes is because a huge number of our users struggled to understand screens and were unable to add fields to request types / issue layouts without getting lost or accidentally modifying the wrong screen (and causing issues to other Jira projects). 

Our solution is focused on making Jira easier to work with and take the emphasis away from screens. 

We did talk to a large number of advanced admins to understand how best to do this without oversimplifying Jira and taking away functionality. 

In Jira Service Management, this has meant a couple of changes:

1. Screens can be overlooked: Less experienced admins can create a request type catalog without interacting with screens at all and the field order of the screen does not impact the request type configuration at all. This lets Jira admins add these fields to request types without having to navigate to the global configuration and identify which screen to update. 
2. Request type configuration can override the view/edit screen(s): If a field is on the request type form, we show it to agents, even if the field is not on the view/edit screen(s). This is because most customers would omit the field from the view/edit screen by accident, resulting in the agent not getting information from end users. 

So, I think you understand why we made these changes. 

But what about your use case of preserving the field order to make Jira products easier to work with? 

We did discuss this internally and made the decision to show all the fields on the project in alphabetical order and include search if the field is not on the project or not readily discoverable. 

While we aren't looking at honouring the field order on the screen on the issue layout or request type configuration, we are looking into alternative solutions that might solve this use case without screens given that we are trying to shift the focus away from them. 

It might be worth having a chat to understand your needs in more detail. 

Would you be open to having a chat sometime in the next few weeks? Click here to book a time that suits. 

[Amanda Boettcher]

Looking forward to Forms attachments functionality 😊

[Lukasz]

Just here to say that I had a team owned JSM project with a form, and wanted to recreate this form in another team owned project. I copy pasted the form content and everything magically worked. Quite impressive! Thanks to whoever at Atlassian made sure this works.

[Brian McCabe]

A related question from someone who is considering a move to JSM Premium in a multi-customer (multi organization, single project) setup ... where in the feature backlog is the ability to provide Request Types on a per Organisation basis? We will have numerous external companies accessing JSM and we want to provide them with their own personalised list of Request Types.

[Cameron Gocke]

@Jehan Gonsalkorale Can you use Forms/ProForma with a Teams Managed JSM project? I would like to be able to add formatted paragraph text to the Request Type that provides definitions for specific fields to users when they submit a request and also to use conditional sections, but with a Teams managed project.

[Jehan Gonsalkorale]

Hey @Cameron Gocke , I saw your feedback come through on the app. 

Yes! You absolutely can. If you have any issues, feel free to reach out to me at jgonsalkorale@atlassian.com. 

Hope that helps!

[Milad S_]

Hi @Jehan Gonsalkorale

Great work. These changes will significantly reduce needing for Jira admin to clean up and jump around. Any update on the rollout?

When you mentioned "All fields for Jira admins", are you excluding this feature from project admins? If a field is available (that meets the project admin requirements), is there any reason not to allow them to use it?

I understand that this will make project admins indirectly change a screen (which is a higher privilege), but as a Jira admin, I would rather not get into these things unless it is necessary. Generally, we are not sharing screens across projects unless it is specifically required (so changing a screen does not affect other projects).

Regards,

Milad

[Sebastian Irle]

Hi,

is there a new estimation on the custom fields for team managed projects feature?
It would really help us to be able to fill the options of select lists by API also for team managed service management projects.

Best regards

Sebastian

[Jehan Gonsalkorale]

Hi @Sebastian Irle, we are working on this as a priority so hope to release it in the coming weeks. We encountered some unexpected complications that have caused delays but these are being resolved by the team. 

I am hoping we see this released late this month or early next month. 

I'll provide an update once it is released.

I hope that helps,

Jehan