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
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 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.
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
Hi, I’m Billy York. I’m a Cloud and Datacenter Management MVP, specializing in monitoring and automation. Here you’ll find posts about AzureMonitor, LogAnalytics, System Center Operations Manager, Powershell, Hyper-V, Azure Automation, Azure Governance and other Microsoft related technologies.