Share This Post

Monitoring Service Manager Incident Changes through Orchestrator

Service Manager has nice workflows to apply specific templates or fire off a subscription when specific fields change on your incident.  However, when processes start to become complex, applying templates through workflows tend to get complicated and cumbersome.  Also, when doing complex subscriptions based on support groups or classifications we have to build out each subscription based on the group we are e-mailing which can also start becoming a maintenance nightmare.

Orchestrator provides an easier view of your process flow than trying to piece it all together in Service Manager.  The problem with this approach is the difficulty to determine what changed in the incident when in Orchestrator to determine whether to tee off a process.  Luckily, Service Manager is very extensible to let us accomplish this goal. 
The approach that I used was to extend the incident class to account for “monitoring” fields. In this example, I’m going to extend the incident class and add a new field for monitoring the support group dropdown field.
1)      Open up the SCSM Authoring Tool found at:
2)      Create a new unsealed Management Pack and name it to what makes sense to your company.  In my case, I used <CompanyName>.Incident.Extension.  
3)    Select the Incident Management Library from the class browser and right-click the incident to select view.  You will then see the sealed incident management library in the explorer view.
4)     You can then extend the incident class by right-clicking on the incident and selecting “extend class”.
5)     You will then be prompted to save this extended class to an unsealed management pack, which we can select the one we just created in step 2.
6)     Once you get it saved, you can now view the properties of that extended class and modify the class name to something more descriptive.  Remember this name because it is the name will show up in your Orchestrator view when selecting the class to monitor and update.
7)     Click on “create property”.
8)     Type in the internal property name with no spaces.
9)      We can then modify the “Name” to have spaces and to look professional.
10)   Once you have all the Custom monitoring fields specified, save your unsealed MP.
11) It is best practice to then Seal your Management Pack and then import it into Service Manager.
 12)   Once it has imported successfully, open up a new incident and view the new Extensions tab along with your extended class property.
Once this has been completed, we can easily use Orchestrator for the remaining of our process.  Below is scenario where I want to e-mail different distribution lists based on their support tier group only when the ticket support group has changed (not each time an update has happened).
1)      Use the “Get Object” in the SC 2012 Service Manager Integration Pack.
2)      Select you SCSM server and then select your new extended Incident class.  In my case, I called it “Incident Monitoring” and then select that you want to monitor new and updated incidents.
3)      Next we want to go to the Utilities area and drag over a Compare Values object.  In this case, we simply want to do an initial compare between our current Support Group selection against the extended Support Group Monitor value.
4)      Our link Properties will then determine if the values have changed and we can determine what happens based on true or false comparison value.  You need to do this for each link to the next compare value object.  In this case, we are looking for a false compare to let us know that something has changed.
5)      For each of our Tier 1 – Tier 3 branches we need to also use the compare value object to let us know what branch to take. 

6)      We use the same logic for our link properties except this time we are looking for a true comparison to move down that path.
7)      Next, we want to send the e-mail to the appropriate support groups.  We can use the published data based on the incident to give our support groups more information in the ticket.
8)      Finally, we want to update the incident and store the current support group value so we can determine next time the incident has been updated whether we need to send out an e-mail to our support groups.
9)      Use the nice Runbook tester to validate your logic and then let it loose to monitor your Service Manager incidents. 
Happy Orchestrating!
Bob Erwin

Share This Post

Leave a Reply