When you start with incident management there will always be a discussion about incident status.
The discussion will be about who will close the incidents?
If want to go straight to the MP – https://gallery.technet.microsoft.com/SCSM-Incident-Change-04594d9b
Auto Close Incidents Task
The preferred way should be to have the Service Desk set the incidents to resolved and have closing of the incidents automated after x days. This way you leave x days for the end user to respond, if not close the incident. Once it is closed it stays closed and if the end user still requires assistance he needs to log a new incident.
For auto close there are several solutions to be found on the internet.
This is it, hmm no need to blog about this right?
Well there is more to it.
Remove Close Task
The second question would be “Can you remove the close task?” Sure although changing access to a task is a hassle in SCSM it can be done. So you create new roles based on the existing ones and you unselect the close task.
Cool! Well customer here you are, enjoy yourself with incident management change status in SCSM!
You cannot remove close task!
Why ? would one ask well you don’t really have to be a rocket scientist to discover that you actually can close the incident. Just select the “evil” Other Status which let you change to ANY state you want.
You remove the “other status” but how would you set the incident to pending or a custom status? You can’t!
Evil Other status task – NO WAY change status without comments!!
To be honest the other status task is plain evil from a incident manager perspective. Let me explain:
When I started in IT as a helpdesk employee I had a manager who would slap you silly if you changed the status of an incident without telling the reason WHY you changed the status. This is because using the status in an incorrect way is basically a sophisticated way to cover your *ss.
If you wanted to play games all day you could set the status of your incidents to pending and have a nice day off !
Another one which was used was closing and incident or resolving it because the end user was a real pain and his issue was in general more a flame on the help desk employee’s. By the time he logged the incident again you made sure you where at some “customer” doing your thing.
Believe me I have seen many other versions of this as well !
The key in here is always have progress in you incidents, and give a reason why you changed the status because especially the last one affects the End User in question. Which is a business employee making money for the business and in the end pays your check every month!!!
In the end the incident manager should have an operational process in place to catch these little rascals in their act.
But if you can provide some assistance here you should.
Changing status in SCSM the correct way – Friendly Other Status
Because another customer asked to remove the close task I figured I should be ahead of things to come and pointed them out although I can remove the close task this will leave the “evil” one for anybody to use.
Since I have some skills in building extensions I figured I would write the code to change status in a correct way.
Cool Solution right !
The whole idea was you cannot see any difference at first and the cool stuff will be once you open the Other status, which is the friendly one !
When you click the “other Status” a new form will open where you can select the other status.
And need to fill in comments.
These comments are nicely placed in the action log:
And off course “custom Statuses” will also be available!
What About the close task?
If you would still require the close task to be available but want to benefit from the comments added to the other status?
You need to edit the XML accompanied with the solution. There are comments in the XML what to uncomment to get the close task!
If you want to separate the tasks from the grouped version please take a look at – http://gallery.technet.microsoft.com/Service-Manager-2012-b558f3ac
Auto Close Cireson – http://cireson.com/apps/auto-close/
Hiding Console Tasks – http://blogs.technet.com/b/servicemanager/archive/2011/06/24/hiding-console-tasks.aspx