Recreating SCSM mail subscriptions with SCORCH

Dries_Werckx

Hello

I am attempting to recreate a SCSM mail subscription with SCORCH to add some functionality to it.
The mail should be sent when a support group in an incident has been changed.

I monitor the change in a support group for an incident and go on from there
The problem is, that when an incident is created, the support group "changes" also (from nothing to a value I suppose).
I don't want the mail to send when a ticket is created, only when the support group is changed from a value to another value.

Thanks in advance.

Geoff_Ross

I see, I'm with you.

So few things to mention...

1. The above setting will only trigger when a incident is updated, not when one is created just as you need, but it will trigger on all updates, not just updates to Support Group. So if something is updated, eg the description is changed, as long as the Support group is still Service Desk, it will fire off again. Probably not what you want.

2. You can achieve what you need with a few different methods.

a) If you want to stick with Orchestrator, you will need to use a Power Shell activity and use SMlets and the Get-SCSMObjectHistory cmdlet. Schedule it to run every 5 mins (for example), get all Incident where the last modified date is in the last 5 minutes. Then get each one's history, and check if a support group change is in the last 5 mins of history. If so, you know support group has changed and you can trigger your notification.

b) This could be done with the Cireson SMA connector, which allows you to trigger an SMA runbook when a certain property on a work item is changed eg support group. That would save having to do with work with the history.

c) You could also build your own Workflow within SCSM to trigger only when Support group changes

d) The simplest method: This can be achieved with the Cireson Notify Analyst App. You just specify an SCSM Email Template and it will send that to everyone in the support group when it changes. Simple!

Geoff

Brad_McKenna

Dries, for the Monitor Object activity, do you have both triggers selected: New and Updated? Also, have you added any filters to the object to further ensure only current incidents with a support group change is triggering the monitor? 

brad

Dries_Werckx

Thank you for your answer Brad.
I only have the "Updated" trigger selected (right now only when it is updated to "Service Desk").
I have no further filters applied, because I did not know what to filter on to filter out the newly created incidents.

Geoff_Ross

Hi Dries,

Check out https://community.cireson.com/discussion/1696/powershell-version-of-action-log-notify#latest

Hope that helps.

Geoff

Dries_Werckx

Hi Geoff
Thanks for the response. I did set it up like that, but I need to filter out the newly created incidents from the already existing incidents that update their support group.
This is how it is set up now (I did not filter on the link between the activities):

I will have to make a runbook for every support group, but that's not the main issue right now

Geoff_Ross

I see, I'm with you.

So few things to mention...

1. The above setting will only trigger when a incident is updated, not when one is created just as you need, but it will trigger on all updates, not just updates to Support Group. So if something is updated, eg the description is changed, as long as the Support group is still Service Desk, it will fire off again. Probably not what you want.

2. You can achieve what you need with a few different methods.

a) If you want to stick with Orchestrator, you will need to use a Power Shell activity and use SMlets and the Get-SCSMObjectHistory cmdlet. Schedule it to run every 5 mins (for example), get all Incident where the last modified date is in the last 5 minutes. Then get each one's history, and check if a support group change is in the last 5 mins of history. If so, you know support group has changed and you can trigger your notification.

b) This could be done with the Cireson SMA connector, which allows you to trigger an SMA runbook when a certain property on a work item is changed eg support group. That would save having to do with work with the history.

c) You could also build your own Workflow within SCSM to trigger only when Support group changes

d) The simplest method: This can be achieved with the Cireson Notify Analyst App. You just specify an SCSM Email Template and it will send that to everyone in the support group when it changes. Simple!

Geoff

Dries_Werckx

Hey Geoff
Thanks for the clear answer. I think we are leaning to answer B since we need Orchestrator (we have an email template in SCSM which works perfectly, but it didn't provide enough detail in the way we wanted).

Christopher_Carver

This is a similar issue I had with e-bonding tickets from an external vendor using ServiceNow and our SCSM solution. Knowing when to do what.

I do not use monitoring activities on SCSM tickets. The reason is the activity is not truthful and prone to accidental triggering if the SSM service process has to be restarted or routine work flow from SCSM transverses all of the tickets periodically. A lesson learned so hard, I still have the voice mail bruises to prove not to use that activity. Enough with the warning, onto a solution.

Here is the PowerShell to extract tickets that have changed since you last looked. You will need a simple table to keeps track of the time on when you last looked and then update the table after retrieving the tickets. So this PowerShell will give you what you want on modified tickets.

$lastSynced = '\`d.T.~Ed/{020EB2F8-4BB2-4AFA-9F0C-4FA6B5DDB772}.Last_Synchronized\`d.T.~Ed/'

$currentDateTimestamp = (Get-Date).DateTime

$currentDateTimestampStr = $currentDateTimestamp.ToString()

$retCode = 0

$retInfo = ""

$retTrace = ""

try

{

  $ErrorActionPreference = "Stop"

  Import-Module SMLets

  $tickets =  @()

  $srs = Get-SCSMObject -Class (Get-SCSMClass -Name System.WorkItem.ServiceRequest$) -Filter "LastModified -gt $($lastSynced)" | Where-Object {$_.Source.DisplayName -eq 'DatAvail - ServiceNow'}

  $irs = Get-SCSMObject -Class (Get-SCSMClass -Name System.WorkItem.Incident$) -Filter "LastModified -gt $($lastSynced)" | Where-Object {$_.Source.DisplayName -eq 'DatAvail - ServiceNow'}

  foreach( $sr in $srs )

  {

    $tickets += $sr.Id

  }

  foreach( $ir in $irs )

  {

    $tickets += $ir.Id

  }

}

catch

{

  $retCode = 2

  $retInfo = "Could not retreive DatAvail tickets from SCSM."

  $retTrace += "`r`n$(Get-Date -format 'u')`t Exception: $_.Exception" 

} 

Once you have the tickets you can then retrieve each ticket and get the support group. I would use another table that kept a record of the last known support group. If the ticket was not found, I'd add it to the table. If the ticket was found and the support group is different, I would send the email to the new support groups. 

Pros:
- Need two simple SQL tables to keep everything in sync; last synchronized and a last known support group lookup.
- Prevents email trashing within 5 min intervals. If a ticket is assigned by accident to the wrong team and then switched to the right team in the 5 min. window, then no email is sent to the wrong group.

The idea of traversing the ticket history is interesting as I never tried that, but it still requires a ticket lookup to know what history to pull.

Peter_Miklian

I agree with @Christopher_Carver.

For support group (SG) and assigned analyst changes notification we run 2 monitoring runbooks checking IR and SR for Update.

They invoke runbook with PowerShell activity which keeps track of currently assigned user and group for each ticket. If current SG/analyst is different from the last logged, notification e-mail is sent (=invoke another runbook).

What's wrong in our solution is that the runbook is using CSV file as the log for given ticket. We need to move to SQL table as @Christopher_Carver suggested.

SR1042060.txt

The side benefit of this solution is that you can query your database to get information like 'how long are tickets assigned to given SG/analyst?'