Looking for advice: Filtering support groups by category or other input

Tom_Hendricks

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:

• 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] **

Adam_Dzyacky

My knee jerk reaction is option number 4. My specific implementation would be an SCO/SMA runbook that is added as an Activity to the Incident so that it always runs once (on create no less). This could be a really generic runbook like "Determine Initial Support Group based on Classification." Going this route, it's less likely to break any other automation you have in place and if anything else - improve it, since newly created Incidents leveraging this IR template would also feature this RB activity and thus begin conforming to this standard.

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.

Conner_Wood

I think you'll have to make a custom task which would use ServiceManager Support Group Enums and the mapping you gave each one.  The issue is it's a monumental amount of work to do something like this considering SCSM isn't known for dynamic smart forms, quite the opposite in fact.  Cireson has shown promising things with Advanced Request Offerings with dynamic questions, but this is still a step beyond all that.

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?

Tom_Hendricks

I am going to implement the suggestion from @Adam_Dzyacky in QA and we will test it out.  Thanks for the well-reasoned response!  I still have some concerns about ongoing sustainability of the mappings, but I intend to address those with process and documentation.  My initial thought would have been to create a SCORCH job to monitor new tickets, but I am liking your idea of kicking it off from an RB activity, the more I consider it.

@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!

Conner_Wood

Tom_Hendricks said:

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

Tom_Hendricks said:

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!

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:

<p>CategoryGUID1==SupportGroupGUID1
CategoryGUID2==SupportGroupGUID1
CategoryGUID3==SupportGroupGUID1
CategoryGUID4==SupportGroupGUID2
CategoryGUID5==SupportGroupGUID2
CategoryGUID6==SupportGroupGUID3
</p>

I think you've narrowed down your solution, I wish you the best of luck.