Handling Custom Management Packs

Christopher_Carver

We have developed a large catalog of sealed custom service request management packs to meet the unique needs of our service teams/functional towers. I request that a new tab be added to service requests similar to that of the SCSM console showing the extension fields that make up the custom management pack for the service request.

Without this ability custom reporting have proven difficult when the report is based off custom fields that should be entered by the analyst regarding the SR. Today our analysts are hand adding the fields inside of action notes or the description of the SR. Forcing reporting to parse through freeform text looking for key field designators. It would be far easier for our reporting automation to just key off the SR custom field.

seth_coussens

Christopher, I've moved this into the FAQ area and converted it to a question. Let me explain a bit more below and give you some insight on this.

At Cireson, we currently have no plans to support 'inherited classes' and thus 'inherited class' extensions. Looking at the above request, this appears to be what you are indicating you have in place today, as the Console extensions tab would segment the different extensions for you in that tab. As you probably are currently experiencing, this can be quite the mess. With the portal we've decided to take a completely different approach.

First of all, we promote the use of generic property extensions of the base class rather than creating inherited classes. While we have some limited support for inherited classes today, there will be no work going forward to maintain that capability, though we obviously will not set out to break it either. If you are using inherited classes today, it's just something to be aware of.

As for the reasons that we promote base class extensions vs inherited classes, there are many:

• Reduces the number of columns in the database by reusing generic extensions across different request types
• Allows for less confusion when using automation systems such as orchestrator as you can focus on a single class for your activities.
• Promotes flexibility without having to constantly extend the class within SCSM
• And more...

We've implemented something different in terms of allowing you to create different forms for different groups of users. This allows you to tailor the form experience to a group of users to show them the values you want, in the way you want. This also allows you to recycle properties for different request types.

All of that is possible out of the box. You can even customize your form to show a different tab or section for each of those properties... and give the properties a different title that makes sense to the end user, while behind the scenes the property is actually called ' text01'. You can use this same 'text01' property in multiple locations on the custom form and give it a different title each time to indicate what relevance it has.

If this doesn't work for you still, we also have extensions that can dynamically change the form based on user properties or form properties (such as TemplateId) that will load the aspects of the form you desire for the user and hide the aspects that don't pertain to that ticket type.

You'll see more flexibility around this in the future, but you most likely will not see us improve our support and functionality around Inherited Classes.

seth_coussens

Christopher, I've moved this into the FAQ area and converted it to a question. Let me explain a bit more below and give you some insight on this.

At Cireson, we currently have no plans to support 'inherited classes' and thus 'inherited class' extensions. Looking at the above request, this appears to be what you are indicating you have in place today, as the Console extensions tab would segment the different extensions for you in that tab. As you probably are currently experiencing, this can be quite the mess. With the portal we've decided to take a completely different approach.

First of all, we promote the use of generic property extensions of the base class rather than creating inherited classes. While we have some limited support for inherited classes today, there will be no work going forward to maintain that capability, though we obviously will not set out to break it either. If you are using inherited classes today, it's just something to be aware of.

As for the reasons that we promote base class extensions vs inherited classes, there are many:

• Reduces the number of columns in the database by reusing generic extensions across different request types
• Allows for less confusion when using automation systems such as orchestrator as you can focus on a single class for your activities.
• Promotes flexibility without having to constantly extend the class within SCSM
• And more...

We've implemented something different in terms of allowing you to create different forms for different groups of users. This allows you to tailor the form experience to a group of users to show them the values you want, in the way you want. This also allows you to recycle properties for different request types.

All of that is possible out of the box. You can even customize your form to show a different tab or section for each of those properties... and give the properties a different title that makes sense to the end user, while behind the scenes the property is actually called ' text01'. You can use this same 'text01' property in multiple locations on the custom form and give it a different title each time to indicate what relevance it has.

If this doesn't work for you still, we also have extensions that can dynamically change the form based on user properties or form properties (such as TemplateId) that will load the aspects of the form you desire for the user and hide the aspects that don't pertain to that ticket type.

You'll see more flexibility around this in the future, but you most likely will not see us improve our support and functionality around Inherited Classes.

Christopher_Carver

Thank you for letting me know Cireson's stance. We reviewed the difference between class extension and inherited classes and in our environment class extensions for service requests would not be a wise path to take managing the data going forward. There are other CIs where class extensions are more desirable as the CIs are passed between classes. Let me explain our scenario.

At inception we had 75 uniquely defined service requests ranging from 4 to 20 unique non-generic custom properties per service request. We deploy 4 new service requests per month since launch earlier this year with no end in sight for new service requests as the tool grows in popularity across our teams. Having a all-in-one service request class would contain a growing amount of unused fields. So far we have had no issue with Orchestrator handling the different types of custom service requests. The only issue is editing the extension data from the Cireson Portal. Maybe you know something we do not and a day of reckoning will befall us.

Thank you very much for taking the time to explain how Cireson handles the issue. This is a testament to the excellent custom support care that will keep us as a customer.