A customer of mine recently asked me if it’s possible to easily see (and later also use reports for), how many times an incident was moved between support groups. There are different approaches for this and in this post I will describe a simple solution for that.
Additional information: make sure you also read part 2 –> https://marcelzehner.ch/2014/06/24/create-a-report-for-support-group-changes/
First we extended the incident class with a new “int” property “Support Group Changes” with a default value of “0” (zero). This can either be done in the Authoring Tool or using Visual Studio and VSAE.
To increment the counter we created a custom workflow in the Authoring Tool that checks for support group changes. Every time this happens, a PowerShell script will be executed that increments the value of the “Support Group Changes” property.
The workflow uses a trigger and a singe PowerShell script activity.
Lets take a look at the trigger first. This workflow should trigger every time a support group will be changed for an incident. So I configured the trigger to watch for objects of the incident class that will get updated.
In the advanced criteria section we can configure the criteria to make sure the workflow does not trigger for all incident updates but only for support group changes. The configuration we want cannot be configured in the GUI. So for now we just select some dummy entries.
We will change the criteria to the correct settings afterwards. Now lets first take a look at the PowerShell script activity. First we need the incident ID from the incident that triggered the workflow and pass it to the PowerShell script activity. This configuration will add a “param” section to our script. I used “IRID” as the variable name and passed the incident class property “ID”.
This is the script we are using. As you can see, the variable IRID can now be used to pass the incident ID.
Here is the full script. As you can see, after importing the detault SCSM PowerShell module I get back the incident object, increment the actual value of the property and update the incident afterwards.
$regkey = “HKLM:\SOFTWARE\Microsoft\System Center\2010\Service Manager\Setup”
$ModuleFile = “System.Center.Service.Manager.psd1″
$SMInstallDir = (Get-ItemProperty -Path $regkey).InstallDirectory
$FullModulePath = $SMInstallDir +”PowerShell\” +$ModuleFile
import-module $fullmodulepath -force
$class = Get-SCSMClass -name system.workitem.incident
$incident = Get-SCSMClassInstance -class $class -filter “Id -eq $IRID”
Update-SCSMClassInstance -instance $incident
remove-module system.center.service.manager -force
Done! After saving the MP, we now need to change the criteria for the trigger. Open the MP with an XML editor and search the criteria.
Now change the criteria configuration to this.
This configuration will check if the support group value is different from “Pre” (before the change) compared to “Post” (after the incident was modified and changed). If this is the case, the workflow will be triggered and the number will be incremented. So after importing the MP and copying the appropriate dll file to the installation directory of Service Manager on the workflow server, the workflow will work and increment the value every time the support group will be changed.
Pingback: Create a report for “Support Group Changes” | marcelzehner.ch
Pingback: Create a report for “Support Group Changes” | Building Clouds Community