Some of our customers have bad habit to reply old ticket emails when submitting new problems/tickets. Then the mail goes to closed ticket and goes unnotified. Is it possible to route messages destined to closed ticket to a new ticket or reopen old ticket and notify tier1?
Scot the "problem" was (when i investigated this) that once a ticket has reached a stage of the type "END" (in SD Def) you cannot go back to middle.
that was by design, i don't think this changed with SD1.3
I've also done some additional testing as well and you all are right. I apologize for the confusion.
In response to @Hans you can select all the stages when you re-open a ticket. You cannot change the due date or the closed date. It does update the closed date when you close it again but that is all. The escalation also did not work for me.
Since my "bad" previous suggestion is not working as expected, I would still check for the public note being added in the procedure and then send an email back to the submitter using a message template that states the ticket was previously closed and to please submit a new one. Don't re-open the ticket.
There is an unorthodox way of doing it (I reached out to some of my team for ideas) but it also has challenges. The unorthodox way is to create a "Final" stage and make that the end stage. Your "Closed" stage becomes a middle stage and the only stage it can select is "Final" (for middle stages you have to have a stage they can go to). When you close a ticket, status = closed and stage = closed your closed date is populated and you can send your closed notifications. For all visual purposes it looks closed. Then when you receive an email reply, it looks like the ticket is re-opening but really you are just moving it to another stage and your escalations all work. Problem lies with the closed date is still there when you move to another stage (same as before) and your technicians if they click on the stage field will be able to see Final as a stage they can select. If that field is not used and hidden then it's not a problem.
But my best recommendation is don't re-open ticket and the change procedure sends the submitter a note that the ticket is closed. But I think this is a great feature request that allows a ticket to be "officially" re-opened.
I am struggling with this myself. The problem I have is identifying a proper trigger that is specific to the instance of a user replying to a ticket that is closed. Currently I have checks in the Change Procedure to evaluate if status = closed, if [$EditingUserName$] = *System* (which it is when a note is appended by replying with the ~ticid code).
When those conditions are true, an email is sent to the assignee and the ticket is reopened. I also have a check on [$LastPublicUpdate$], which should require that the last public note added be within 10 seconds of the change, to prevent false positives. This last bit is giving me trouble on events like the Goal & Escalation procedures. These are running after the ticket is closed, which triggers the change procedure with [$EditingUserName$] = *System*, which reopens tickets when I don't want them to be. I'm going to try clearing all Goal and Escalation timers when the ticket moves into the Closed Stage.
I hope this gives you some ideas and warns you of some of the pitfalls. If you (or anyone else for that matters) knows of a more direct way to evaluate whether or not a change was made by a reply email (rather than a user or the system), I'd be very interested to know.
Actually I can see that part of my issue may be that the LastPublicUpdate value on my system is incorrect. I have submitted a ticket to support.
Hi Everyone, Scott is correct that is how you check and address the user replying to a closed ticket but we also add a couple of different steps to address the false positives. Here is sample procedure that we sometimes include in our implementations in service desk in the change procedure:
If status = closed
If stage = closed
If [$EditingUserName$] contains System (I always use contains but you can use equal)
If [$ChangesAsHtml$] exists A public note was added (this is to address any false positives, emails always come in as public notes)
Sets Status = ReOpen (this can be any status you want)
Sets Stage = Tier1 (this can be any stage you want)
The issue then with goals and escalations are addressed because you have moved the ticket into a new stage. Just be aware that it will follow your stage escalations and goals from that stage assigned unless you put logic in to address.
I hope this helps both of you with ideas on how to set it up
Thanks Michele. I would have never found "If [$ChangesAsHtml$] exists A public note was added". I'm going to try it right away.
are you sure closed tickets can be "re-opened" ? (is this a change is SD1.3?) i remember Gary W telling me that once the stage was "closed" (final stage) you can reset the stage to whatever you like with procedures but it does not actually re-open the ticket / reset to stage Tier1.
if this is changed it would be very nice !
I tried Michelles suggestion in change prodecure script but so far tickets seem to stay closed. I'll do some additional testing tomorrow.
I will test again as well, it has worked but now I'm second guessing myself. I'll update when I complete.
looking forward to see your update !
This is for sure working for me. The stage and the status are both what they should be after the "reopen". Change procedures and goal procedures, and everything else so far all treat reopened tickets as they should. However, I did notice that one of the tickets that I had reopened for testing did not run it's escalation procedure when the escalation timer expired. I haven't found a way to clear the "closed" date. Maybe that has something to do with it.
Nothing conclusive yet; I still have more testing to do.
@Scott. This is indeed what i thought/said you can reset it but it does not actually re-open it. Can you select the stages you can normally select on a re-opened ticket?
i hope i am wrong :-)
Ah yes, you got me there. My stages are used very lightly so I had not even noticed. Did you try and setup your stage processing so that Closed to In Progress (or whichver open stage you like) is an option?
I think I'll try that tomorrow.
Email notify is suitable for our use. Thanks.
Knowing our restrictions, we'll be good as well.
@Michele - what seems to be the problem here isn't necessarily the lack of ability to re-open a ticket. The underylign problem is that there is no clear vision of what defines an "open" ticket versus a "closed" ticket. This is one area where the Kaseya Service Desk seems to be lacking its customary transparency and control. Other than for KB articles, I haven't found any documentation that mentions any special functionality about the "end" stage and certainly none that explains how the end stage is permanent.
Also, I had a problem when we first started with the "statistics" function. We had both a "completed" status and closed "status" that were brought in from our previous ticketing application. The problem was that the statistics page only recognized "Closed" status tickets as actually closed. I had to log a support request to figure this out. The problem was easy enough to solve (consolidated the two entries under "closed"), but it didn't make sense when there is an "end" Stage-type.
So, rather than a limited "re-open" function, what I'd prefer to see is that the definition of a "closed" ticket be consistent across the service desk, published in the documentation and controllable by defining a stage, stage type, or some variable. If there are factors that prevent this, I'd would at least like to see the documentation of what defines a closed ticket for statistics, reporting, escalation and anything else that a closed ticket might affect.
Personally, it would make the most sense to me to count the "end" stage type as a closed ticket for all purposes, and lift the restriction on moving out of that stage. I look forward to seeing whatever changes you guys make in a future revision.