Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

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.


Log in or Sign up to comment