How are others managing custom fields with request types?

Matt Harford April 28, 2021

Hi There, 

We are using JSM Cloud and for the last several months have been building out forms / request types as we move more of our work over. 

I'm wondering how others are managing new custom fields? 

If we add a new custom field, and associate it to the screen scheme for our default issue type, it shows up in every single request type context view which is a huge pain - it clutters everything up, and makes it hard to find the fields we are looking for. 

In order to fix this, we've been going in to each request type, and "hiding" the fields that aren't relevant to those request types. The more request types we have, the more time consuming and tedious this is to do. 

Has anyone come up with a way to address this?

Thanks so much,

Matt 

1 answer

0 votes
Brant Schroeder
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 28, 2021

@Matt Harford 

We have a specific screen scheme for our service desks.  We associate the new custom fields with the screen(s) on that scheme when we created for the service desk.  This is easy to do when prompted during the custom field creation process (Associate the field services to a screen)  We also limit what projects and issues it is associated with in the context so it does not show up on other issue types.

Matt Harford April 29, 2021

Thank you, Brant! 

Do you then need a new scheme for each and every request type, if you want the request types to have different fields associated with them?

Brant Schroeder
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 29, 2021

@Matt Harford 

Once you create a screen scheme you can associate it with a specific project and when you associate it with a project you can associate it to all or select issue types in that project.  

Matt Harford April 29, 2021

I think our problem is, we want to use only a handful of issue types (IE, Service Request) and have many more request types:

Request a new account, help with 2FA, register a device to connect to the WiFi, etc.

These all require different custom fields, and each "agent view" has to have the customer fields hidden manually. If I'm understanding correctly, creating new screen schemes won't really help since they can't be applied to different request types, only issue types.

-Matt 

Brant Schroeder
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 29, 2021

@Matt Harford 

Why are you hiding them manually.  I have a service desk with over a hundred different custom fields and 50+ request types.  They all share 4 different issue types and a single screen scheme.  Since each request only uses a small portion of the custom fields the agent only sees the custom fields used on each request type.  This is because if a custom field is empty then it will not display on the view screen.  We handle the edit screen, which I believe is your issue, by breaking our custom fields up into tabs that group the fields by the areas that they are serving.  Then the agent usually only has one or two tabs to hit if they are editing the issue outside of the view screen.  Also agents raise a request through the portal which prevents them having to search for fields.  Hope that helps.

Like David Cahill likes this
Steven Miller April 30, 2021

I can't seem to wrap my head around your proposed solution.

So our request types are broken down into a few general categories:

  • Internal User Requests
  • Customer Requests
  • Agent Requests

These users all have access to different systems with their own issues so they all have separate custom fields that do not apply to other requests. We currently only use 'service requests' issue types. For the screens that we add fields to, we use the built-in Request Fulfilment ones.

If I create a custom field and associate it with the above screen, it will absolutely get added automatically and show in the agent view when view/editing a ticket, even if it is empty. Which is what we do not want, because I have to go in and hide/remote it manually from the requests it does not apply to.

 

So your solution with tabs, if that you would have ( in my case) a separate tab for each request type that would always be visible on each request, and it would be up to the service desk user to pick the right one to fill out, correct?

 

Do you have your 'create issue' screen modified at all per request type? That's another issue I was running up against, where I have not worked out a way display certain fields based on request type when creating the issue. Changing it as-is simply shows the fields for all requests types.

Matt Harford April 30, 2021

I agree, I also don't think I understand. We want to keep the "context fields" empty, except for the fields related to that specific request type. Without the ability to "hide by default", every single request type looks horribly cluttered. Tabs might work, but with nearly 100 request types, that would be far too tedious to manage. 

Brant Schroeder
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 30, 2021

@Steven Miller 

Let's make sure the issue here is clear.

Service desks are used to receive requests through the portal.  Thus the ability to create request types.  So in your case, you have additional requests that you are servicing for internal requests and agent requests.  This issues are not being raised in the portal and are being raised as a standard Jira issue.  If you do this then yes every single custom field will show on the create screen and you would either need to create a new issue type for each request and manually hide in context or have a separate screen sheme.

There is a feature request to rectify this issue that you can vote for here: https://jira.atlassian.com/browse/JSDCLOUD-195

Matt Harford April 30, 2021

@Brant Schroeder We are using the customer portal - it's not the customer side that is the problem, it's the agent side. All of the custom fields associated with the issue type show up on the right side (context fields), unless they are manually hidden, on a per request type basis. 

Brant Schroeder
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 30, 2021

@Matt Harford Yes that is correct.  As stated above if you are using the Jira create button to actually create issues then you will have to do a lot more work to organize the custom fields.  You will either need to control them by issue types, context, or screens.  You also have the option of using tabs.  As stated above request types and raising a request through the portal is the way that the service desk was designed to be used.  If you are raising the request internally through Jira then you will have additional work to do since it is now treated like any other project in Jira.

Matt Harford April 30, 2021

@Brant Schroeder That is what I mean - we are not using the Jira create button, we are having users create issue through the portal. Once the issues come in, it's how they look for our staff working on them that is the problem. They are not hidden by default if they are empty. Is that how it is supposed to work? 

Brant Schroeder
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 30, 2021

@Matt Harford 

Yes, when you create a custom field by default it should end up in hidden when empty.

Here is an example.  I created this custom field today and then added it to the proper screens.  When I go to the request type it is in hide when empty by default.

Capture.PNG

 

This means that the view screen will stay very clean and will allow the service desk team to easily manage issues. 

The edit screen will be very busy though.  Say a user does not provide some information that is needed and the agent has to update the issue.  When they click edit then they will see all the fields.  This is why we use tabs to help organize the custom fields by areas so they have less scrolling to find the field they are looking for.

David Cahill March 24, 2023

This is why, for now at least, you should make a separate issue type for each request type that requires custom forms and fields. We do this with things like specific order forms. This makes quickly identifying these issue types easier anyways and allows them to have different workflows if needed.

Pro-tip: We also use Bundled Fields via the Extension for Jira Service Management Add-On to make these fields and screens much easier to manage and only need one custom field per complex form total on the back-end.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events