Options
Looking for advice: Filtering support groups by category or other input
Tom_Hendricks
Customer Super IT Monkey ✭✭✭✭✭
I am considering different ways to implement a dynamic Support Group filter for Incidents and Requests, which would shorten the list of groups based on what category is chosen. The intent is to reduce errors and increase efficiency (what else?).
For example, when a category is chosen--let's say "Printing"--the Support Group dropdown list is filtered to show only the Tier 1, Tier 2, and Tier 3 groups who can handle printing requests or issues.
The filtering of the list seems to be the easy part, by comparison. The difficult part is deciding where and how to store the mapping of categories to groups, so that it can be easily maintained as our processes and resources change.
Ok community, how would you suggest designing this without creating a maintenance quagmire?
Some examples to get the discussion started:
For example, when a category is chosen--let's say "Printing"--the Support Group dropdown list is filtered to show only the Tier 1, Tier 2, and Tier 3 groups who can handle printing requests or issues.
The filtering of the list seems to be the easy part, by comparison. The difficult part is deciding where and how to store the mapping of categories to groups, so that it can be easily maintained as our processes and resources change.
Ok community, how would you suggest designing this without creating a maintenance quagmire?
Some examples to get the discussion started:
- Hard-coding the values in an array object within Custom.Js (I almost want to downvote myself for including that!)
- Creating a separate DB, perhaps with a web service to call, that stores the category and support group values and presents a join table/view
- Creating each of the categories and support groups as objects in the CMDB, with relationships, and trying to keep them in sync with the enum values
- Store the mapping in a flat file and parse it using SCORCH/SMA after the ticket has been saved, then update the ticket
- ** [Your infinitely better suggestion here] **
0
Comments
I like this because it requires little to no training of staff, allows you to act on your own via SMA/SCO, executes once (on create) so you can get the group right "the first time" still allowing re-assignments later, and removing the user from onus of picking a support group.
Something like this could be really beneficial in the SCOM to SCSM connector as SCO/SMA will be the thing performing the Assignment as opposed to hard defining it into the IR template within SCSM.
The Reason I suggest a task is that Cireson has created the "Assign to Analyst By Group" Task. Honestly I think it's your best chance at learning and mastering your own tool. After all, the best learning example is a working example.
In terms of designing the mappings, I do recommend it be hardcoded in the Custom Task js. Remember that trying to do what Cireson did with their Portal Group Mapping Settings requires expert knowledge and ample time very few have. First get it working, then work on optimizing.
Ultimately, no one but you will continually support your customization, when something goes wrong, do you really want to be troubleshooting multiple points of failure?
@Conner_Wood, I do not disagree with your points. In fact, I made some of the same while initially pushing back against this customization. At the end of the day it was classified as a requirement, since the old ticketing application had this functionality. Also worth noting, I do not need this to work in the console, since we do not use it except for administration.
I also agree in principle with getting it working first, even if it involves hard-coding, then improving it in later iterations. However in practice, I expect a fairly high rate of change over the next couple years, and I cannot be the bottleneck for updates. I need for others with different skills to be able to update it without my help.
If we keep the mapping out of the (JS or other) code, I can easily enlist help from others to update the mapping file that SCORCH will use. It would be more difficult provisioning extra MSDN licenses and finding folks who are comfortable with JavaScript to pitch in. Also, keeping updates to the mappings separate from our JS code will make it simpler to avoid deploying dev code to Prod before it is ready.
I plan to build this such that the mappings are stored in a file, and we will see what problems arise from locking, etc. A DB table seems like a better approach in many ways, but I want it to be as simple as possible to update. I do not want SQL skill to be a prerequisite to helping maintain the list, nor do I have the resources to build a front-end to that table--even a ridiculously simple one. I welcome other ideas and thoughts on this, though!
I know exactly how you feel having to deal with the loss of functionality from a previous ticketing system. Ah, by task I specifically meant the tasks that are on the Cireson Portal when on a ticket form to learn from, good catch.
Well said @Tom_Hendricks you clearly know your work environment! Putting your users experience first is most commendable as well. If you plan to have the list itself being used in Scorch, you could make a small runbook that returns your list as a comma separated value string, and in that small runbook it could load a file that was formatted as you specified from the "Text File Management" section. Though it's up to you to decide how to format the file, personally I'd format the text file to look like:
I think you've narrowed down your solution, I wish you the best of luck.