Best practices for adding numerous custom fields for various teams' request types in service desk

Chad Goodrich September 5, 2018

Background for our IT department's implementation... We have a single service desk project for our help desk agents who act as the tier/level 1 and 2 support. Then we have multiple "inbox" projects for all of our various tier 3 support teams who all handle different issues, such as networking, data center, application development, etc. If issues cannot be handled by level 1 or 2 support, a linked issue is created in a tier 3 inbox project for the appropriate team. We also follow the ITSM framework.

We are at the point in our implementation of service desk where we are setting up request types for all of our various services. The tier 3 teams have all requested custom fields so they are able to receive the necessary information to resolve the issue.

This is where I'm stuck. I know how to implement the custom fields, but I don't know what the best practices are, especially so that management is sane down the road. I do not want to create additional issue types for each group's service requests, incidents, etc, so that they can all have the appropriate screens. We want to stay with the basic ITSM types: incident, problem, service request, etc. The configuration options available seem to want me to create additional issue types though, such as Networking Service Requests, Data Center Service Requests, etc.

I can just create all of the custom fields and have them visible on the necessary request types in the portal, but then to make them available on the issue itself, I'd have to add ALL of those custom fields to the edit/create and view screens in the service desk project, which seems like the wrong way to go, even if I added them to different tabs. The custom fields would also have to be available within the tier 3 inbox projects to which they apply.

I've explored some add-ons, such as creating a Bundled Field with Extension for Service Desk, and Issue Templates, but they all didn't quite do the trick. I've also explored writing rules to append those fields to the description on issue creation, but that also seems like a lot of customization to do.

We also floated the idea of using multiple service desk projects, one for each team, and using an add-on (Queues for Jira Service Desk) to combine them into a single queue for the help desk agents. This would allow us to add contexts to our custom fields to make them more reusable. However, we are trying to break down request types into services, not teams (again ITIL). And these multiple service desks would be less than ideal from the customer's perspective when viewing the portal.

Again, I know how to do the above. I just don't think that's the correct way to do it. Any suggestions would be greatly appreciated. Thank you in advance.

1 comment

Chad Goodrich September 10, 2018

Accidentally added a duplicate, after I saw this one had been marked as spam. Please add comments to the other post. https://community.atlassian.com/t5/Jira-discussions/Best-practices-for-adding-numerous-custom-fields-for-various/td-p/884035

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events