P. Nordqvist Posted May 30, 2018 Posted May 30, 2018 Hi, We currently have a routing rule that updates a request if the request number is in the email. Now we have the issue stated in this thread [https://community.hornbill.com/topic/12292-automatic-reopen-ticket-based-on-an-email/] What happens is that the routing rule updates the call and reopens the call. This is NOT what we want. In this case we simply want the email to update the call but NOT change the status. For this the user have an option in the service portal by clicking "It's still not working" button. How can we avoid that an email update changes the status to open? Kind Regards Per
Dan Munns Posted May 30, 2018 Posted May 30, 2018 If the call is closed and the email is opening it again then you can use the settings: app.email.routing.rules.allowClosedCallUpdates.IN and app.email.routing.rules.allowClosedCallUpdates.SR in the admin console under Home > Hornbill Service Manager > Applications Settings. IIRC the setting will not allow email updates to closed calls at all, however the email should find its way into your Inbox and you can attach to the call if required. I know this isn't exactly what you are after but it should work as a work around in the mean time.
P. Nordqvist Posted June 1, 2018 Author Posted June 1, 2018 Hi @Dan Munns, Thanks for your reply. These both settings you're mentioning are set to "Off" and they don't help us at all as the use case we have is when the requests having the status Resolved. What I don't understand is why an email update do also change the status of the call. The email update should JUST update the call, nothing else. In the workflow we have a step after the call has been resolved to wait for a status change, and for some reason this update that happens also updates the status and reopens the call. How can we change this behavior?
Victor Posted June 1, 2018 Posted June 1, 2018 3 hours ago, P. Nordqvist said: What I don't understand is why an email update do also change the status of the call. The email update should JUST update the call, nothing else. @P. Nordqvist the call status might change as a result of an email update if the service on the request has sub-statuses configured there and the option to change the sub status on a customer update is enabled. Do you have these configured for your services? (screenshot below is just an example of how this can be configured)
P. Nordqvist Posted June 1, 2018 Author Posted June 1, 2018 @Victor, yes. You are right. We have it configured like this. I though this will only happen if the call has the status "On-Hold" and the customer updates the call. What would be your propose how we shall change the settings to achieve what we want? I guess the best would be to clear the "On Customer Response..." value to nothing. In this case the Analyst will have to change the status from On-Hold to Open manually when the customer updates an On-Hold call, right? Kind Regards Per
Victor Posted June 1, 2018 Posted June 1, 2018 3 minutes ago, P. Nordqvist said: I though this will only happen if the call has the status "On-Hold" and the customer updates the call. @P. Nordqvist it depends if the sub-status (that request is suppose to change to as a result of a customer update) belongs to a main status which is different than the current main status of the request (hope this makes sense) 3 minutes ago, P. Nordqvist said: What would be your propose how we shall change the settings to achieve what we want? Thinking more of it, I don't think the sub-status change on customer update is responsible for the request being reopened... because the sub-status change should be just this: a sub-status change and it should not affect the main status (unless is changed from "active" to "on hold" or the other way around, which is not the case here). I suspect this happens in the process. Can you PM me a copy of the BP configuration file so I can have a look, please?
P. Nordqvist Posted June 1, 2018 Author Posted June 1, 2018 @Victor, I think I know what happened. So I believe everything works as it should. I had the setting app.request.allowResolveCloseWithoutAnalyst set to ON which is the default. What happened then is that an analyst resolved a call without having any analyst assigned. Before the call was resolved it had the status "New" without any sub-status. When it was resolved the sub-status stayed empty (I set the sub-status in the BP when the call gets assigned to an analyst). In this case the email update changed the sub-status to In progress which I guess caused the call to be reopened. Do you believe I am right in my thoughts? Kind Regards Per
Victor Posted June 1, 2018 Posted June 1, 2018 9 minutes ago, P. Nordqvist said: In this case the email update changed the sub-status to In progress which I guess caused the call to be reopened. The "In Progress" sub-status is an "active" status... the "Resolved" status is also an "active" status so... 10 minutes ago, P. Nordqvist said: Do you believe I am right in my thoughts? No, I don' think so... the email update should only changed the sub-status (in this case from nothing to "In Progress") but not touch the main status which is "Resolved" (because is an "active" status)... So I still think is something in the process doing this
Victor Posted June 1, 2018 Posted June 1, 2018 @P. Nordqvist so I could not find any fault with the process ... ... So right now I do not know why a customer email updating a request would change the request status... I need to look at the events log to trace the code execution here... do you have a request reference example along with a date and time of an occurrence of the issue?
P. Nordqvist Posted June 1, 2018 Author Posted June 1, 2018 @Victor, I think we leave it as it is. Now change the setting so an Analyst cannot reolve a call without having an owner. After this change the call will always have the sub-status "In progress" when it is resolved, which means the issue is fixed. I cannot reproduce the issue after this setting is done. Cheers Per
Victor Posted June 1, 2018 Posted June 1, 2018 2 minutes ago, P. Nordqvist said: After this change the call will always have the sub-status "In progress" when it is resolved, which means the issue is fixed. Ok, if you think so, but I am not 100% convinced ... In any case, if it reoccurs let me know
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now