Recreating SCSM mail subscriptions with SCORCH

Dries_WerckxDries_Werckx Customer IT Monkey ✭

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.


Best Answer

Answers

  • Brad_McKennaBrad_McKenna Customer Adept IT Monkey ✭✭
    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_WerckxDries_Werckx Customer IT Monkey ✭
    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_RossGeoff_Ross Cireson Consultant Super IT Monkey ✭✭✭✭✭
  • Dries_WerckxDries_Werckx Customer IT Monkey ✭
    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 :smile:
  • Dries_WerckxDries_Werckx Customer IT Monkey ✭
    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_CarverChristopher_Carver Customer Adept IT Monkey ✭✭
    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.
Sign In or Register to comment.