Configuring User Notification

NazOsmanNazOsman Member IT Monkey ✭
I am currently having a problem with keeping my users informed about tickets. Here is a quick overview of what we have.
Configuration: SCSM 2016 with Cireson Portal

1- Originally, I had two notifications. Notification one is to Inform user when ticket is created. Notification two is to Inform user when ticket is resolved. (This was setup for both services and incidents)
2- Soon after, we started converting Incidents (That came through the Exchange Connector) to services in needed be. However, this resulted in 4 total notification to the use. 1st notification when the Ticket is created through Exchange Connector. 2nd Notification was created when ticket is resolved after converted to SR. 3rd Notification when the SR is created, and 4th Notification was created later on when SR is resolved. (An awesome user posted a custom task that did all that automatitally, but it still generated all these notifications non the less since the notifications are handled in a 

3- The spam-y nature of this flow prompted me to disable all notifications so we can convert IRs to SRs without bombarding the user with emails.

I am wondering how others are handling this situation


  • Justin_WorkmanJustin_Workman Cireson Support Ninja IT Monkey ✭✭✭✭
    Maybe the alternative exchange connector will help?  If it's creating the right kind of Work Item up front, there won't be as much conversion and thus fewer notifications?

  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    It has helped in this way, in our environment.

    If you have an email subscription that emails when a ticket is created, and you are creating a new SR ticket, they will get a notification.  Personally, I cannot think of a way to make the subscription smart enough to know that an IR was already created with the same information, even by hand-editing the MP as I have done many times in the past.

    We set SR as our default ticket type, since we typically receive more of those tickets via email (important to note that SCOM tickets arrive through the alert connector, not email!).  It is also easier, IMO, to parse a message for key words that suggest it is an IR ticket, rather than looking for words that suggest it is an SR ticket.  So I have a simple keyword search that overrides the default ticket type to have it create an IR instead, if those keywords are found.  I do plan to contribute this modification to the official build soon as an optional alternative--I need to simplify the way in which it is configured, first.  Alternative to what, you ask?

    What @Adam_Dzyacky created in the most recent version will be even more useful to those who are able to take advantage of it.  You can configure this connector to use Azure Cognitive Services to make the ticket type determination for you.  I am currently unable to make use of this (not for any technical reasons) but plan to implement it when possible.  My keyword search predictably (pun intended!) gets it wrong occasionally, but it has still significantly reduced conversions.  It is possible for Cognitive Services to guess wrong sometimes too, but it has some advantages that should result in a higher success rate.

    Coming back to @Justin_Workman 's point that I agree with, it is far simpler to reduce/eliminate the problem than to find ways to handle it after the fact.  Hopefully the link he provided proves useful!
  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭
    edited May 4
    As much as I do enjoy the SMlets Exchange Connector, I'm understanding of the fact not everyone is comfortable with it given it's open source nature. So it's worth pointing out there may be a way to address this (possibly) without a wholly new connector and those two things are:
    1. Your Notification triggers
    2. Your IR/SR templates

    So first is how you've configured the triggering mechanism for a notification. For example, it may make a great deal of sense to say "Send an Email to the Affected User when an IR/SR moves from New -> Active or New -> In Progress".

    Second to this is then the templates you choose to use. These templates you may set with a default status of Active for Incidents and/or Submitted for Service Requests. In this way, the notification trigger would skip them because the triggering condition wasn't met as they were brought into existence into that final state. In the case of an SR it skips it entirely because the Status is Submitted. Also don't forget that an SR only goes from New -> In Progress when Activities are present. If there are no activities on a brand new SR it moves from New -> Submitted.

    So when it comes to the classic conversion dilemma, the SMLets Exchange Connector does offer a fully autonomous means of figuring out what the Work Item Type should be from the outset (certainly with some error rate as Cognitive Services isn't perfect). But used in conjunction with the above example you should be able to meet business expectations and your goal of minimizing the email noise.
Sign In or Register to comment.