How to inform ex-AssignedTo analyst about the withdrawal

In this post I’d like to share one solution for Microsoft System Center 2012 Service Manager that we were recently asked. One company has a practice to notify not only the assigned analyst about a new assignment to the service desk’s ticket but also the analyst who has been withdrawn from that ticket. It asked us for help in doing that for its Service Manager setup.

It is quite easy to create a workflow in the Service Manager console to inform an analyst about the first assignment but it won’t help if you replace analysts in the form. Ketan Ghelani posted a few years ago a very useful post about creating a custom notification workflow. Ketan explained how we could use “AddRelationship” event to run a notification workflow.

Our first intension was to use “DeleteRelationship” event to do the same to notify an ex-analyst. We perfectly caught the “DeleteRelationship” event but the notification workflow didn’t notify the ex- analyst. It happened because the instance of “AssignedTo” relationship we referred had been deleted to the moment the notification workflow tried to use it.

There are numerous methods to overcome this issue. We’ve chosen to create a new relationship named “Ex-Assigned User” and kept using Ketan’s approach.

We started with defining a new relationship. I created a new management pack (SCUtils.ExAssignedUser.Library) where defined the relationship:

<RelationshipType ID="SCUtils.WorkItemWasAssignedToUser" Accessibility="Public" Abstract="false" Base="System!System.Reference">

<Source ID="WasAssignedToUser" MinCardinality="0" MaxCardinality="2147483647" Type="WorkItem!System.WorkItem" />

<Target ID="WasAssignedWorkItem" MinCardinality="0" MaxCardinality="1" Type="System!System.User" />

</RelationshipType>

Then I sealed the management pack because we had to reference it in other management packs.

Next, we had to create a workflow that will catch “DeleteRelationship” event for “WorkItemAssignedToUser” relationship and created a new instance of our own relationship “WorkItemWasAssignedToUser”. As usual, I used SMlets PowerShell commandlets. To build a management pack with PowerShell workflow we had to use Service Manager Authoring Tool. So I opened the tool and created a new management pack called “SCUtils.ExAnalyst.WorkFlow”. Then I created a workflow using Incident class and condition “When an object of the selected class is updated”. I added Windows PowerShell Script activity to the workflow’s tree. Then I imported the following PowerShell script into the body of the activity:

$a= (get-module|%{$_.name}) -join" "

if(!$a.Contains("SMLets")) {Import-ModuleSMLets-ErrorVariableerr-Force}

# -------------------get classes and objects------------------------

$RC=Get-SCSMRelationshipClass -Name SCUtils.WorkItemWasAssignedToUser

$wi=Get-SCSMObject -Id $WorkItemGUID

$user=Get-SCSMObject -Id $UserGUID

# -------------------remove ex-ex-analyst---------------------------

Get-SCSMRelationshipObject -BySource $wi | ?{$_.IsDeleted -ne "true"} | ?{$_.RelationshipId -eq "90C9BB9F-98F0-B85F-3EA5-55A428B52976"} | Remove-SCSMRelationshipObject

# -------------------create new ex-analyst--------------------------

New-SCSMRelationshipObject -Relationship $RC -Source $wi -Target $user -bulk

#-------------------------------------------------------------------

remove-module -name SMLets -force

The script was quite straightforward and the only tricky part was identifying the GUID of SCUtils.WorkItemWasAssignedToUser. I used this T-SQL select to get it:

SELECT RelationshipTypeId ,RelationshipTypeName

FROM RelationshipType

WHERE RelationshipTypeName like 'SCUtils.WorkItemWasAssignedToUser'

Then I saved it, closed the tool, and opened the management pack in the XML editor. Now I had to crossbreed Ketan’s management pack and SCUtils.ExAnalyst.WorkFlow.xml. The target was to catch “DeleteRelationship” event for “WorkItemAssignedToUser” for Incidents and ran our Powershell workflow. And then did the same for Problems, Change Requests, Service Requests, and Release Records.

I haven’t described all steps required to accomplish the goal and instead provide you with final xml file you can research if you wish.

So we had the new relationship and the workflow that created the instances of that relationship. And we came back to initial Ketan’s way for notification of the analysts but only in our case we targeted the workflow to “WorkItemWasAssignedToUser” instead of “WorkItemAssignedToUser”. I copied/pasted Ketan’s xml code into a new management pack named “SCUtils.Notification.WorkItemReAssignedTo.xml”, then made some changes in the code and added additional email templates for Problems, Change Requests, Service Requests, and Release Records. If you are going to use this solution then you have to edit those email templates because I made them as simple as possible.

To use this solution “as is” you have to have installed SMlets on the Service Manager management server and to copy RemoveAnalyst.dll in Service Manager folder (usually “C:\Program Files\Microsoft System Center 2012\Service Manager”) and then import 3 management packs:

1. SCUtils.ExAssignedUser.Library.mp
2. SCUtils.ExAnalyst.WorkFlow.xml
3. SCUtils.Notification.WorkItemReAssignedTo.xml

Finally, I have to warn that you have to test any new custom solutions (including this one) in your testing environment before deploying in production. I ‘ve attached the archive file with all files I used.

How to inform ex-AssignedTo Analyst about the withdrawal.zip