A smarter way to notify the assignee when the affected user updates his incident

September 16, 2011 Posted by Anders Asp

A common request is to be able to notify the assigned analyst of an incident whenever the incident has been updated by the affected user. And for those who’s been reading my blog for a while know that I’ve described ways to do this before:

Notify the assigned analyst when a customer has updated his incident (Exchange connector)
http://www.scsm.se/?p=167

Minor SSP modifications, part 4 – Changing status of an incident when updated by the End user
http://www.scsm.se/?p=501

Both of those two blogposts is built around changing the status of the incident to be able to trigger a notification to the assigned user of the incident to react upon. There is nothing wrong with that, it works pretty good in fact, but there is one flaw in this design. This flaw is related to the way the Exchange connector works and the fact that we are applying a template to the incident to set the status back to active (for those of you who doesn’t know what I’m talking about, please see http://www.scsm.se/?p=167).

What if someone replies to an e-mail of an incident which has been closed? Well, based upon the configuration we did in the earlier blogpost mentioned above, the exchange connector will apply a template that sets the status back to active and the incident is re-opened. For some this might be acceptable, but for others, it’s not. I visited a customer a couple of days ago who thought this was great if the status of the incident was set to Resolved but not if it was Closed. Instead, they wanted to notify the end user that he or she would have to open a new incident and leave the old incident closed. There is no way to tell the Exchange connector to apply different templates depending on the current status of an incident, so I had to figure out another way to solve it.

Since I couldn’t use the status of an incident to trigger the notifications, I figured we would have to add a new propery to work with instead.

So here’s a smarter way to solve all this:

1. Extend the Incident class with a new boolean property. I will call my property “UpdatedByEndUser”.
(I won’t describe how to do this, but take a look at this blogpost if you need some help http://www.scsm.se/?p=192)

2. Create two incident templates – One who sets “UpdatedByEndUser” to True, and another who sets “UpdatedByEndUser” to False.

This is actually trickier than it sounds (but it’s not hard). The Extension tab is not accessible on the form when creating a template – so what you would need to do is checking the Escalated checkbox for both these templates, then export the management pack in which these templates are stored and change Escalated to UpdatedByEndUser. For the corresponding template, you will also have to change the value from True to False. Take a look at the screenshot below:

3. Edit the Exchange connector to apply the UpdatedByEndUser to True template when an incident is updated.

4. Edit the source code of the Self Service Portal to set this value to True if someones uses the portal to add a comment to their incident.

Open the source code for your SSP (http://www.scsm.se/?p=398). Then open the “Helper.cs” under WebParts and search for “//If it is resolved then reactivate it by changing the status to Active… ” – this should bring you to line 510.

Add this code…

 requestDataItem["UpdatedByEndUser"] = true; 

…to line 523 and line 535. Like this:

Note: This is the untouched code. If you followed the blogpost “Minor SSP modifications, part 4 – Changing status of an incident when updated by the End user” the code should like a little bit different and you might want to revert that change.

5. Create a two new workflows:
5a. One that triggers when UpdatedByEndUser changed from False to True and where the current status of the Incident is set to Active or Pending
5b. One that triggers when UpdatedByEndUser changed from False to True and where the current status of the Incident is set to Closed

Both these workflows would then send an e-mail to the assigned user to inform he/she that the incident has been updated, but they must also apply an template that sets the value of UpdatedByEndUser back to False; otherwise the workflows won’t trigger on recurring updates.

6. You might also want to set UpdatedByEndUser to true when the end user closes the incident from the portal (as requested in this thread http://social.technet.microsoft.com/Forums/en-US/administration/thread/83e3e998-cdde-4b4e-a83d-b17c08485531/)

To do this, open up your Source Code for the SSP again. The Close Request button is actually available on two pages: ViewAllRequests and RequestDetails, but both of these buttons uses a function called “CloseIncidentInternal”, so what we need to do is edit that particular function. This function is located in the Helper.cs file, so let’s open that file.

The function itself start at line 411 (just search for CloseIncidentInternal to get there) but we need to add the following peice of code to line 489:

incidentDataItem["UpdatedByEndUser"] = true;

Compile and deploy the new binaries.

7. Create another workflow that triggers when UpdatedByEndUser changes from False to True and where the status equals closed. Use this workflow to notify the assigned analyst that the end user has closed his/hers incident.

All done 🙂

9 Responses to A smarter way to notify the assignee when the affected user updates his incident

  1. Sjors says:

    Hi Anders,

    Thanks alot for this post, I find it very interesting. I have just begun to configure SCSM 2010 SP1 and have done pretty good so far. Implemented the Send Mail task effectively and have some working workflows.

    Now when I try to implement what you have posted above here, I already get stuck at “1. Extend the Incident class with a new boolean property. I will call my property “UpdatedByEndUser”.
    (I won’t describe how to do this, but take a look at this blogpost if you need some help http://www.scsm.se/?p=192)”

    When I go to that blogpost for help I get even more lost. I feel that I have too few knowledge to succesfully implement this without some pointers.

    For example, what xml should I open in the authoring tool? i am trying to open the incident management xml, but that give me an error:
    http://social.technet.microsoft.com/Forums/ar/systemcenterservicemanager/thread/7d73efbb-29e2-4d0e-a71e-53b7675a0ac9

    Tried to solve that by following the solutions mentioned, but also there I get stuck as I can’t get my head around the template i need to store into another MP?? it’s mentioned in the last post of that chain.

    Hopefully you have the time and the will to point me in the right direction.

    Sincerely,

    Sjors Hollemans

  2. Anders Asp says:

    Hi Sjors,

    As it sounds like you haven’t done any class extensions to the incident class before, you should create a new management pack within the authoring tool to store this in.

    Once you’ve created the new MP, you should locate the class browser and find the incident class. Then right click it and choose view; and if you manage to come that far, the other blogpost you mentioned should be enough to help you get going – otherwise, just post a comment here or send me an email 🙂 (anders[at]scsm[dot]se)

  3. Sjors says:

    Hi Anders,

    Thank you for your tip !It helped me a lot 🙂 I am nearly done with setting everything up. I’ve done everything you mentioned in the blog.

    However, perhaps I’m overseeing something again, but it seems the 2 workflows are not triggered when I update the incident through the portal, it just sets the updatedbyenduser to true but there is no old value that’s supposed to be False. So only when I manually apply the False template and then update the incident, the active/pending workflow triggers and ofcourse sets updatedbyenduser to true again…

    Have tried many changes but nothing works?

    Also, when I close the incident from the portal, the Closed workflow is not triggered at all.. it triggers another workflow I made that sends out an email to the affected user when a ticket status changes from active/pending/updated to closed.

    I also send you an email for this, but i’m not sure you received it so i’m posting here again as well ^^

    greetings

  4. Alexey says:

    Hi Anders,

    is there a way to solve this problem using the built-in functionality SCSM 2012? Testing functionality SCSM2012RC we did not find this feature.

    Thank you.

    • Anders Asp says:

      Hi Alexey,
      This can be solved in 2012 in a similar way – Stefan is going to write a blogpost about that. Give him a couple of days and he should have it published!

      • Fletcher Kelly says:

        Hi Anders,

        Any news on this as yet?
        This would be great for SCSM 2012.
        Would love to have this in place.

        Fletch

  5. Pingback: SCSM.SE » Blog Archive » Notify Assigned to when the Affected User updates an incident from the SSP in SCSM 2012

  6. Corey says:

    Hello,

    I was wondering if you can advise a way for me to notify the Affected User and their supervisor when their case has been resolved.

    Thanks for your time

  7. Pingback: Notifying End Users that Incident is Closed When They Reply by Exchange Connector | SystemCenterPoint

Leave a Reply

Your email address will not be published. Required fields are marked *

*