Service Manager Re-assign Ticket Notifications with Orchestrator

by

I was recently asked to create a notification in Service Manager to notify service desk members when a ticket had been re-assigned to them. No problem? Unfortunately this behavior isn’t native in Service Manager. After poking around on the internet I found a few blogs that showed how you can do it in Orchestrator. Their solutions were OK, but did not fully solve the problem in my Service Manager environment for 3 reasons

1. We already had notifications for when tickets were assigned and the runbook duplicated them.
2. They did not capture all ways for tickets to be assigned, since there are two record types for Incident assignment in Service Manager.
3. I was then asked if we could notify the end user when their ticket has been re-assigned as well.

So the goals are: No duplicate notifications, capture all assignment records and notify both the service desk technician and the end user. Easy enough. Five runbooks later, I have enough content for a new post!

Here are our runbooks in order of how the workflow proceeds.
We have two Monitor runbooks.(only one pictured)

We have the Check Time runbook


We have the Email AassignedTo User runbook




We have the Email Affected User runbook


Lets talk about the two Monitor runbooks. They are exactly the same, they monitor Trouble Ticket Action Log in Service Manager. Except that one filters for Action Type “Task Run” and the other filters for Action Type “Record Assigned.”



We need both types because a service desk member can assign an ticket from the “assign to analyst” field on the right hand side of the Service Manager console and they can also directly input someone in to the assigned to user field within the ticket. These each trigger different log types. Don’t ask me why. So this is our way around it.

Once Orchestrator detects that one of these records has been generated, it triggered the original runbook which generated a second notification in addition to the one generated by Service Manager. So to resolve that, I created an additional runbook to check that the first assigned date field within the ticket was not in the last fifteen minutes.

First we invoke the runbook and pass the SCObjectID to the check time runbook.


The Initialize Data from the Check Time runbook


Now we get the relationships for SCObjectID to get the Incident.


And now Get Incident with filter SC Object GUID equals Related Object GUID from Get Relationship.


Now we need to format the time.


We get the published data first assigned date from Get Incident. However, there is a gotcha, Service Manager records time in UTC, hence the minus five for hours. This is there because in the next format current time we use activity end time from Orchestrator.


Now we format activity end time from Format First Assigned Time with -15 so we can compare the two.

Next we do some PowerShell.


We compare the two dates and if first assigned date is greater than now(remember now is now -15 minutes), we return True.


We return True/False to the runbook and if it is False we proceed with the emails.

The link properties are edited to only proceed if the result is False.


So if the ticket was not first assigned in the last 15 minutes, we invoke the Email Assigned to User runbook and pass it the SCObjectGUID.

The Get Relationship/Get Incident sequence is the same as above. But to get the user we need another Get Relationship with these settings.



The interesting thing I found here, was that the next activities Get Assigned User in Service Manager and Active Directory would run multiple times. I did a text output and found Orchestrator was getting every user ever related to the Incident, not just the current assigned to and affected users. So to resolve this I put a link filter for the assigned to user as shown by the next two screen shots.



Once we get the user in Service Manager, we then get them in AD. For whatever reason, Orchestrator cannot see the email address from Service Manager, despite Service Manager being able to send emails to users. 


Anyway,  this is how I get the user in AD.


 Next, for the email address we subscribe to the Email published data from our Get User Email activity.



The neat thing about the send email activity in Orchestrator is that I grabbed our organizations HTML email template from Service Manager, pasted it it in the body, changed the variables around to the published data from the runbook and it looks like it came from Service Manager.

The email Affected User runbook is exactly the same except the filter after Get Related User is changed to Affected User instead of Assigned to User. You could probably email both users from one runbook, maybe if I make modifications I will update the runbook.

You can also modify the Monitor runbooks so they only have one invoke activity and have them hand off to a master runbook that calls the other runbooks so that they can go back to monitoring for user assignment. In my environment we dont have that many analysts editing tickets that often, but if you have a large service desk that may be something you want to consider.






This runbook is provided as an example and is not production ready, please test in your own environment.  The runbook is provided as is and without warranty.

You can download the runbooks here http://1drv.ms/128j18V