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,
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.
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.
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.
I can't seem to wrap my head around your proposed solution.
So our request types are broken down into a few general categories:
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.
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.
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
@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.
@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.
@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?
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.
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.
This morning, Atlassian announced the acquisition of ThinkTilt , the maker of ProForma, a no-code/low code form builder with 700+ customers worldwide. ThinkTilt helps IT empower any team in their or...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events