It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage
Highlighted

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

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, 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 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

This is exactly one of our struggles, too! We appreciate the flexibility with custom fields (making them is easy), but we're not sure how to scale this into being used for multiple service requests. We want to stick to the standard issue types and don't want these potentially hundreds of custom fields muddying day-to-day use of the standard types, either.

I searched for a best practices document on custom fields and using them in multiple projects, but couldn't find a good resource. If there's something out there we missed, some marketplace plugins to consider, or general advice on what to do or not, that would be so helpful.

After more research, I've determined that Jira just wants us to create additional issue types for these requests.

Comment

Log in or Sign up to comment
TAGS

Community Events

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

Events near you