Thursday, April 26, 2012 4:04 PM
I have extended the Service Request class to include new fields and called it NewEmployeeServiceRequest.
I'd like to create a notification for when the status of an SR based on that class is changed from not equal to Completed to equal to Completed.
I've created the notification template based on the NewEmployeeServiceRequest.
However, when I try to create the notification workflow the template never appears in the drop down lists of notification templates.
Is this because the Service Request Workflow is based off the Service Request class and I've extended it with new fields?
Is there a way to get this notification working?
Thursday, April 26, 2012 5:01 PM
Did you extend the service request class or did you inherit a new class called NewEmployeeServiceRequest from the service request class? From your description, it sounds like you inherited a new class, because in the console you cannot select extensions as the target for anything.
Second, are you trying to create a Service Request workflow or are you trying to create a notification subscription?
Based on your my interpretation of your requirements, my suggestion is this:
Extend the Service Request class (when defining the class, make sure you set Extension="true"..you can do this in XML or use the authoring tool to "extend" the service request class)
Next, in the console under Administration|Notifications|Templates create a notification template based on the Service Request class.
Then under Administration|Notifications|Subscriptions, create a subscription based on the Service Request class and "When to notify" will be "When an object of the selected class is updated". Set your criteria the way you already explained it. After that, you will be able to select the notification template you just created.
Does that fit with what you're trying to accomplish?
Thursday, April 26, 2012 5:15 PM
I'm not sure about the first question. But looking at the new class properties the Base Class is "Service Request" and the Extension field is "False"
What I did in the Authoring Tool was create a new MP and under Classes chose "Create Other Class" and chose the Service Request as the Base Class. I then extended the new class to add additional fields.
It sounds like I inherited?
Can I just change the Extension field in the properties of the existing class to "True" or do I have to create a whole new one?
It also looks like from what you've said I should be doing this through the Subscription Notifications rather than the Workflows, correct? Will that let me notify the Affect User of the service request or just a specific AD user or group?
- Edited by Jay Scovill Thursday, April 26, 2012 5:17 PM
Thursday, April 26, 2012 6:32 PM
Yep, you did an inheritance (more precisely, you "derived" a new class from an existing class). Here's a quick primer on classes in service manager:
Like any standard class hierarchy, a new class can "inherit" from an existing class (it's also called "deriving a new class"). In class lingo, the derived class is the "child" and the class from which it was derived is the "parent". So, a whole new child class is created in the hierarchy. This child class automatically has all the properties of its parent class. Furthermore, you can add your own new properties to the child class if you so choose.
In Service Manager, you can also "extend" a class. Instead of deriving a whole new child class, you're actually "adding properties" onto an existing class. There is no "parent" or "child" concept. So, when you extend a class, it has all of the new properties you defined as if they had been defined right out of the box. (on a side note, "extensions" are actually classes under the hood, but Service Manager treats them differently...hopefully that's clear :) But it's not really important in this context..the important part is that you understand there are "new derived classes" and "class extensions"..two different concepts)
I think you can change the "extension" field to true, but you may have to delete the MP from service manager and re-import it (I'm not sure, I've never tried that before).
It's important to understand that once you have defined your class extension "NewEmployeeServiceRequest", you won't use it or target it explicitely in Service Manager. In Service Manager you will continue to target and use the "Service Request" class..it will simply have all the new properties you defined in "NewEmployeeServiceRequest".
While setting up a subscription, you can select "static" and/or "related" recipients of the notification. Since you're using service requests, I'll assume you're on SCSM2012. When selecting the "related recipients" of a subscription, you'll click "Add", and on the right you'll select the "Assigned to User".
Give that a try :)
- Marked As Answer by Jay Scovill Thursday, April 26, 2012 7:21 PM
Thursday, April 26, 2012 7:06 PM
Thanks for the detailed info Aaron. It makes a little more sense now.
One thing I'm still unclear of is what the functional difference between an inherited and extended class is in the context of what I'm trying to do. IOW, do I really need to either change the Extension property or recreate the class, or can I just use it as is without any changes and create my subscriptions/notifications, etc based on the Service Request class?
And I didn't even notice the Related Recipients screen in the Subscription Wizard! I should have did one more click!
Thursday, April 26, 2012 7:21 PM
Just as an update to this, I left my inherited class as-is and created the subscription using the Related Recipients and my notification when a service request was marked as Completed was successful!
This is exactly what I was shooting for.
Thanks for your help Aaron!
Thursday, April 26, 2012 7:28 PM
In your case, an extension is "adding properties to the service request class" that you can use for service request notification subscriptions, workflows, etc. Further, everytime a new Service Request is created, you can fill out your new properties on that service request object (or retrieve those new properties in the case of a notification)
If you were to derive a new class from the service request class, notification subscriptions and workflows would have to target that new class. And if you created a new Service Request object, it would _not_ have any of the new properties from that derived class because the derived class is a "child" class, and therefore a separate entity. (If you have kids, it's similar to how they inherit your personality, but you don't really inherit their personality :) )
Another way to think of it (if this helps) is derivation means you'll have two different classes.. A or B and you can use one or the other. Extension means you'll have 1 class, A+B and you'll use A for workflow targets, etc.
Before I muddy up the waters with anymore talk about classes, why did you want to extend the service request class? What are you trying to accomplish? (I can guess, but I'd rather you explain it so we're both on the same page :) We may be able to discuss a different strategy)
Thursday, April 26, 2012 7:38 PM
I want our HR people to be able to submit a service request when a new employee is onboarded with their first, last names etc so I can automate the user account and mailbox creation.
I've created a new service request class (derived from the SR class in this case) and have extended it (I right-clicked on the new class and clicked on "Extend") to add the required fields to the new class. I then created a new SR template from that new class. I've used that template to create a service offering in the portal which collects all that info and then passes it all to a runbook activity and Orchestrator to execute the account and mailbox creation script. When all that is done and the SR is status Completed it sends a notification to the HR person (Affected User) with all the relevant details.
At this point it's functionally working as I intended. Just tweak time now.The reason for extending the class is that I didn't want to pass a bunch of variables through the Initialize Data runbook activity and keep on invalidating the runbook every time I changed something. As per Travis Wrights and others advice on best practices for runbooks I just pass and ActivityID variable (mapped to the Object ID of the runbook activity in SCSM) to the runbook and use other activities to get the runbook activity and SR GUIDs so I can grab the info directly from there.
- Edited by Jay Scovill Thursday, April 26, 2012 7:42 PM
Thursday, April 26, 2012 8:19 PM
ahh, I see..you derived a new class, then extended that new class? That's actually unecessary. When you derive the new class, you can add as many new properties to it as you wish, you don't have to extend it. Extension is really only necessary for adding properties to a class sealed in another MP. (For example, you can't go into Microsoft's management pack and add a new property to their Service Request class...so you "extend" it in a different management pack). So instead of deriving then extending, you can just derive.
From the description of your scenario, you are, in effect, creating a new class type for every service request you plan on implementing.
The problem I see is with the class form. You won't be able to use the Service Request form to display/modify the properties of your new class because the Service Request form only targets Service Requests, not your new class. You'll still be able to view your new class _with_ the Service Request form (because it's a child class of the service request class), and you'll see all of the properties of the service request that your class inherited..but you won't see the new properties. (And you can't extend the service request form to see them because the service request form has no knowledge of the service request class' children)
Is that going to be a big deal for you? In other words, are you expecting that people will be able to open the service request form and see the properties for NewEmployeeServiceRequest?
Thursday, April 26, 2012 8:29 PM
At this point, if I open a service request that has been submitted via the portal in the Work Items all the info is there in both the main page of the service request and the Extensions page.
So I don't think it should be an issue. However, this has all been done in my test lab and I'm not confident I'll be able to copy the MPs over and import them into the production environmnet (it's always failed in the past). In that case I'll have to recreate all this anyways and at that point I can stick to your suggestion and just extend the SR class instead of both inheriting and extending it.
I guess my only worry about making it more complicated than it needs to be (as it seems I've done now) is that I might run into some sort of limitation down the road because of the way I did it.
- Edited by Jay Scovill Thursday, April 26, 2012 8:30 PM
Thursday, April 26, 2012 9:01 PM
The hiccup I saw was that you couldn't put your new class fields on the service request form itself, but I did learn something new..derived class properties show up in the Extension tab :)
Personally, I wouldn't just extend the service request class for every type of service request..otherwise you'll have lots of type-specific properties on _every_ service request.. (afterall, do you really need the "new user name" property on the "request an exchange mailbox" service request?)
Deriving new Service Request classes might make more sense. It isolates your service request types from each other. And derived service request classes have only those properties specific to its purpose.
So, like I said, you can derive new service request classes, but you don't need to extend them afterwards..just add your new properties to the derived child class.
If you're interested in a different strategy, the way I've always done it is to create "related" classes that describe a common class (like a change request or service request). Conceptually, it's similar to what you've done, but instead of deriving a new class, I relate a new class (through a common relationship type). Service requests actually do something similar out of the box..a service request can be related to the request offering that created it. It provides context for the service request type..for example, when I query my service requests, I can find the "create a mailbox" service requests by simply looking for service requests with a related "create a mailbox" request offering. One of the advantages over class derivation is that I can create a completely custom form for the related class. (granted, you can create a completely custom form for your derived classes as well, but reproducing the out-of-the-box service request form functionality for that derived class form might take a while!)
I'm not saying that's better or worse than your strategy, it's just another strategy to consider :)
- Edited by Aaron Croasmun Thursday, April 26, 2012 9:20 PM
Friday, April 27, 2012 1:07 PM
Yeah, that was my rationale for using derivations of the class (even if I didn't really know what I was doing at the time!). I don't want every service request to contain these fields. Just the one for new employee onboarding.
So, again, just to clarify, the steps involved in deriving the class rather than extending it would be to just open the Authoring Tool, create a new managment pack and then right-click on Classes, Create other class, select the Service Request as the base class and then go on adding new properties (rather then right-click -> Extend Class)?
As for related classes, is that done through the Authoring Tool? Not finding anything about on Google.
Thanks again for the effort your putting into this. It's helping me a lot!
Tuesday, May 01, 2012 12:46 PM
Yep, that's correct.
Relationships can be created in the authoring tool similar to how you create properties. (The buttons are side-by-side). Relationships have a source and a target class and, when a relationship instance is created (such as a "created-by user" relationship), it basically says "this source object incident (IR123) and this User (Bob Smith). Bob Smith is the creator of this incident".
If you haven't read up on the Service Manager blog, yet, I recommend it. It's got some very good information about how class hierarchies, extensions, and relationships are handled in Service Manager.
Here are a couple posts to get you started :)
Sunday, May 06, 2012 12:36 PM
Sorry for jumping in on this thread, but it's basically exactly what I've been battling with the last couple of days, and thanks to reading this I think my path is subscriptions to fix my problem so BIG thanks for that.
My issue is that i wanted to add new fields to service and incident requests, but i wanted to keep the default MPs as they were, not cluttering them up with fields that might apply to different areas or departments. Thought it might look messy. Plus I want different form layouts, to make tickets quicker and easier to read for analysts working on different tasks.
I'm totally new to this also, and maybe the way forward is really to extend the class properties for the Service and Incident MPs, and then extend the forms as well? I guess if that works all the built-in workflows will work as well. It doesn't really matter if there's a ton of added fields under the extensions tab if the front form is customized.