Avoid an email update changing the request status to open?

[P. Nordqvist]

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]

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]

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]

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]

@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]

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]

@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]

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]

@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]

@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]

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