Service Request Area
I was wondering how everyone approached the issue of the "Service Request Area" list that is located in a sealed management pack?
I know there are resources on TechNet to create another list, mapping on the console form and hiding the "old" list.
And I guess then that new list's GUID will have to be specified in the SR portal form to ensure the enumerations work correctly.
What I'm thinking of doing is to use one list for SR's and IR's but my concern is that it will require a lot of changes for reporting and dashboarding to select the new list.
It will be interesting to see how everyone approached this issue and what advantages and disadvantages there are of the chosen option.
Best Answer
-
Tom_Hendricks Customer Super IT Monkey ✭✭✭✭✭I would do it differently now, if I were starting over. But I created a custom list and hid the default.
It seemed like the better option in nearly every way, at the time. There is wide support for this method in the Cireson products, and it worked flawlessly in both the console (which we do not use, except to create templates) and the portal. It even works in the Outlook console, which we are sadly unable to use here, but that is another story for another time.
However, here are a couple notable drawbacks that you should consider:- The Cireson Portal will not include your custom category in the WorkItems table, and you will therefore not see the category in My Work/Team Work/etc. nor in the Work Item Search (?!?!?!?!)
- Your custom SR area/category list will not make its way into the Data Warehouse unless you write a custom MP to force it to.
It should be noted that there are pros and cons to doing this the other way, which will be more or less impactful depending on how your users access the portal and SCSM:
Pros:- Less custom work to get the categories to show up
- Work Item Search support
- Data Warehouse support without complicated MP's
- All the default OOB areas/categories will always be in the console form drop-downs unless you handle this with custom code in your XAML form
- All the default OOB areas/categories will always appear in the data warehouse tables
- All the default OOB areas/categories will always appear in the portal unless you follow a procedure to hide them from portal lists. There are instructions on how to do this all the way at the bottom of this support KB (ignore the top, since it doesn't apply to this kind of enum). (tl;dr: mark them in the DB as hidden). This is undone if you ever truncate your enumeration table in the portal and rebuild it, however.
6
Answers
It seemed like the better option in nearly every way, at the time. There is wide support for this method in the Cireson products, and it worked flawlessly in both the console (which we do not use, except to create templates) and the portal. It even works in the Outlook console, which we are sadly unable to use here, but that is another story for another time.
However, here are a couple notable drawbacks that you should consider:
- The Cireson Portal will not include your custom category in the WorkItems table, and you will therefore not see the category in My Work/Team Work/etc. nor in the Work Item Search (?!?!?!?!)
- Your custom SR area/category list will not make its way into the Data Warehouse unless you write a custom MP to force it to.
I have an SMA job that forcibly inserts the SR category into the WorkItems table on a ~2min. delay so that it will at least appear in My Work, etc. to be sorted grouped and filtered by (it's just null for all SRs if you don't do something like this), but this feels like a hack.It should be noted that there are pros and cons to doing this the other way, which will be more or less impactful depending on how your users access the portal and SCSM:
Pros:
- Less custom work to get the categories to show up
- Work Item Search support
- Data Warehouse support without complicated MP's
Cons:- All the default OOB areas/categories will always be in the console form drop-downs unless you handle this with custom code in your XAML form
- All the default OOB areas/categories will always appear in the data warehouse tables
- All the default OOB areas/categories will always appear in the portal unless you follow a procedure to hide them from portal lists. There are instructions on how to do this all the way at the bottom of this support KB (ignore the top, since it doesn't apply to this kind of enum). (tl;dr: mark them in the DB as hidden). This is undone if you ever truncate your enumeration table in the portal and rebuild it, however.
Because of this inconceivably bad decision by Microsoft that has not been addressed after nearly ten years of complaints by what I assume to be nearly all customers, you are going to have problems with this no matter what you choose and your decision revolves around which problems you prefer to have vs. the others.I think I will go the route of creating the new categories in the current list and then just disable them in the Cireson DB. I will then script it so that if I truncate the enum table, it will be disabled again.
I guess it is better to stick with what M$ provides and use the Cireson platform to change what I want to be seen.
Once again, thank you. I was really considering the custom list procedure, but that might have caused some issues in the future.
Hello Team,
Is there any way to bring custom list in Cireson portal category list instead of default list?
Thanks in Advance,
Manas
Hi Team,
Any update on the above issue?
Thanks and Regards,
Manas