You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.