Auto - Reopen Tickets if customer reply back

[ajohny]

Can someone please how to change the Hornbill system to auto re-open a ticket if a email is received to it after it has been resolved.

[Steve Giller]

@ajohny I've moved this to the Business Process Automation forum as I don't expect that you would be using ITOM for this process.

There is an example of the two-stage closure process on the wiki which should allow you to set tickets to be re-opened.

[Philip Walker]

Thanks for your reply Steve.

We already have the 2 stage closure process in place.

We just need to set it so that when a customer emails back in with a reference number in the subject, that it re-opens the ticket when it is resolved.

(the system auto applies emails to a ticket when there is a reference number in the subject of the email)

[Steve Giller]

Without seeing your Business Process we can't be sure, but it would appear that the Request Status does not change when the Auto Responder applies an email response.

Reviewing the Request Sub-statuses page might allow you to adapt the existing two-stage process for this.

[Philip Walker]

Hi Steve,

Thanks for your reply, but unfortunately that page doesnt help us.

Surely this is something that other people are struggling with?

Is there any one else that could help us? We are missing emails from our customers that are updating resolved tickets and we dont see the reply as the system auto adds the email to the ticket.

Thanks

Philip

[Victor]

@Philip Walker Re: "auto re-open a ticket"

Currently this can only be achieved via an existing workflow (BP) for a request. It would be the workflow that would perform this "re-open". However in order for a workflow to do this it needs to be a running workflow(*). This means that you would need that workflow active for as long as you need the "re-open" to happen on the request. This is where the request sub-statuses come into play. In theory you can have the workflow suspended at a "Wait For Status Change" node. This will be the point from where the workflow will do the "re-open". Second you need sub-statuses configured on the request so when the routing rules apply an email to a request, will trigger a status change which in turn will resume the workflow which will perform the re-open. The main consideration here is actually how long will the workflow be active as it is not recommended to have indefinite running workflows or workflows that are active for a long period of time.

(*) a running workflow or a workflow instance represents a workflow that has not yet been completed. Once a workflow is complete it can no longer perform any actions and it cannot be re-started.

[Philip Walker]

I think I am in the right place here. Let me know if I am not:

Then I right click and do this?

Then which one do i select?

Thanks in advance

[Victor]

@Philip Walker - I think we need to be a bit more creative here.

We need to have an active sub-status configured on the service having the "trigger on customer response" option enabled. An active status is new, open or resolved. The fact that resolved is an active status is somewhat problematic for the "Suspend Wait For Status Change". When the autoresponder applies the email an triggers the sub-status change, because the sub-status is associated with an active status, there is no actual status change so "Suspend Wait For Status Change" will not resume. Ideally the "Wait For Status Change" would work with sub-statuses but it does not (not currently anyway).

Once could still achieve the above by not having the request resolved. I have seen this implemented in other instances where there would be a sub-status named "Resolved" associated with the on hold status. So when the analyst "resolves" a request, instead of resolving (as in the request status) it makes use of this sub-status to indicate the request is resolved. If this is implemented then "Suspend Wait For Status Change" can now work on autoresponder updates because request status is on-hold and the autoresponder update will change the status to an active status. This has the additional benefit that the SLA resolution timer can be paused and resumed each time the request goes to "Wait For Status Change" (because the request is put on hold at the time). I hope this makes sense, I know is not very straight forward.

Maybe @Martyn Houghton has something around these lines implemented din their instance (iirc, might be wrong), if so would it be possible to give us some advice here if so?

[Martyn Houghton]

@Victor @Philip Walker

 

We too have the issue of the limiting factor of the scope of the suspend nodes. Setting the request to parent status of Resolved and using the Pause Timers node will trigger the showing of the resolution confirmation buttons in the portal but then you hit the issue you are having how to suspend/wait for expiry. Its been a while since I looked at this so will have a another look and see if there another way round this.

Cheers

Martyn