Configuring User Notification

NazOsman

Hello,
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 8.4.3.30

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_Workman

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?
https://community.cireson.com/discussion/2471/an-smlets-based-exchange-connector

Tom_Hendricks

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_Dzyacky

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.

Justin_Workman

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?
https://community.cireson.com/discussion/2471/an-smlets-based-exchange-connector

Tom_Hendricks

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_Dzyacky

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.

NazOsman

@Adam_Dzyacky, May I just compliment your efforts and work with the SMLets Exchange Connector?

This thing is soooooo much more superior than the MS Connector.

I setup the connector is 2 minutes.
Setup the MS Cognitive Services in 2 minutes.

It is crazy how simple it is. I don't have much data yet on how to well the Text Analytics service is doing, but it is better than nothing for now.

I have a feature request though! I am not sure if it is possible or not.

Can you setup the Incident/Service Urgency and Importance based on the Text Analytics score?

Say for example, I setup 0-80% to default to an Incident, and 80% to 100% to default to a Service Request.

Now, I can take that 0-80% and say, if the score is 0-20% make it very important/urgent, if it is 20-60% make it medium importance/urgency, and if it is 60-80% make it lease important/urgent.

Same with Service request, say, 80% is the most urgent/important service request, and the importance/urgency decrease the more positive the content is!

Not even sure if it is a valid way to look at it, but the thought came to mind and I wanted to see what you think!

Thank you again for your help, the connector you created is SUPER!

Adam_Dzyacky

Appreciated @NazOsman. I'm always glad to hear how much this resonates with folks.

On the topic of "how well is Text Analytics doing?" I recently punched up a blog post on it What WOULD HAVE Suggested Knowledge Articles/Request Offerings suggested?. This actually extracts a few key functions from the connector provide a means to see how well the last month's of Incidents/Service Requests would have done.

On the feature request, what you describe was one of my original talking points about this feature seen here on GitHub. Ultimately this Issue turned into the dynamic IR/SR feature. However, this doesn't by any means prevent the feature from further being leveraged within Work Item created. Just need to get the PowerShell added into do this. I'm currently working on getting some documentation written up around multiple mailbox configuration, but the v1.4.5 is openly taking requests for an October release. If you're up for it and have a GitHub account (this also lets you do things like follow the repo, raise issues/requests, etc.) I'd actively encourage you to Fork the repo and make these changes!

Adam_Dzyacky

Raised - Use Azure Cognitive Services Text Analytics API to set Urgency/Priority