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 🙂
